Interactions entre le boîtier de commande et la télécommande

image du clavier et du boîtier de 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 de 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 , tels que le boîtier de commande et la télécommande.

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

Vue d’ensemble

Dans cette rubrique, nous expliquons ce que vous devez prendre en compte dans votre conception d’interaction (ou ce que vous ne faites pas, si la plateforme s’en occupe pour vous), et nous fournissons des conseils, des recommandations et des suggestions pour créer des applications Windows agréables à utiliser, quels que soient l’appareil, le type d’entrée ou les capacités et préférences de l’utilisateur.

En fin de compte, 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). Prendre en charge les appareils préférés de l’utilisateur, rendre le focus de l’interface utilisateur clair et unique, organiser le contenu de sorte que la navigation soit cohérente et prévisible, et donner aux utilisateurs le chemin le plus court possible à ce qu’ils veulent faire.

Notes

La plupart des extraits de code de cette rubrique sont en XAML/C#; Toutefois, les principes et concepts s’appliquent à toutes les applications Windows. Si vous développez une application Windows HTML/JavaScript pour Xbox, case activée l’excellente bibliothèque TVHelpers sur GitHub.

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

Notes

Étant donné que les boîtiers de commande et les télécommandes Xbox prennent en charge de nombreux comportements et expériences de clavier Windows, ces recommandations sont appropriées pour les deux types d’entrée. Pour plus d’informations sur le clavier, consultez Interactions clavier.

Fonctionnalité Description
Interaction et navigation en mode focus XY La navigation avec focus XY permet à l’utilisateur de naviguer dans l’interface utilisateur de votre application. Toutefois, cela limite la navigation à quatre directions : haut, bas, gauche et droite. Cette section apporte des recommandations pour y remédier ainsi que d’autres considérations.
Mode de la souris La navigation au focus XY n’est pas pratique, voire possible, pour certains types d’applications, telles que les cartes ou les applications de dessin et de peinture. Dans ce cas, le mode souris permet aux utilisateurs de naviguer librement à l’aide d’un boîtier de commande ou d’une télécommande, tout 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 ciblé. Cela permet à l’utilisateur d’identifier rapidement l’interface utilisateur via laquelle il navigue ou avec laquelle il interagit.
Activation du focus L’engagement du focus nécessite que l’utilisateur appuie sur le bouton A/Select d’un boîtier de commande ou d’une télécommande lorsqu’un élément d’interface utilisateur a le focus pour interagir avec celui-ci.
Boutons matériels Le boîtier de commande et la télécommande fournissent des boutons et des configurations très différents.

Boîtier de commande et télécommande

Comme le clavier et la souris pour PC et la fonction tactile pour les téléphones et tablettes, le boîtier de commande et la télécommande sont les principaux périphériques d’entrée pour l’expérience « 10-foot ». Cette section présente les boutons matériels et leur fonction. Dans les sections Interaction et navigation en mode focus XY et Mode souris, vous découvrirez comment optimiser votre application en cas d’utilisation de ces périphériques d’entrée.

La qualité du comportement du boîtier de commande et de la télécommande lors de la première utilisation dépend de la prise en charge correcte du clavier dans votre application. Un moyen efficace de vous assurer que votre application fonctionne correctement avec le boîtier de commande/télécommande est de voir si celle-ci fonctionne correctement avec le clavier sur PC, puis testez-la avec un boîtier de commande/télécommande pour déterminer les points faibles dans votre interface utilisateur.

Boutons matériels

Tout au long de ce document, les boutons seront appelés par leurs noms fournis dans le schéma suivant.

Schéma affichant les boutons d’un boîtier de commande et d’une télécommande

Comme vous pouvez le constater sur le schéma, certains des boutons pris en charge sur le boîtier de commande ne le sont pas sur la télécommande, et vice versa. Bien que vous puissiez utiliser des boutons qui sont uniquement pris en charge sur un périphérique d’entrée (pour rendre plus rapide la navigation dans l’interface utilisateur), n’oubliez pas que leur utilisation pour des interactions critiques peut créer une situation dans laquelle l’utilisateur se trouve dans l’impossibilité d’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 le périphérique d’entrée qui les prend en charge.

Bouton Boîtier de commande Contrôle à distance
Bouton A/Sélectionner Oui Oui
Bouton B/Précédent Oui Oui
Bouton multidirectionnel Oui Oui
Bouton Menu Oui Oui
Bouton Afficher Oui Oui
Boutons X et Y Oui Non
Stick analogique gauche Oui Non
Stick analogique droit Oui Non
Gâchette gauche et droite Oui Non
Gâchettes hautes gauche et droite Oui Non
Bouton OneGuide Non Oui
Bouton de volume Non Oui
Bouton de changement de chaîne Non Oui
Boutons de contrôle multimédia Non Oui
Bouton Muet Non Oui

Prise en charge des boutons intégrés

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

Clavier Boîtier de commande/Télécommande
Touches de direction Bouton multidirectionnel (également stick analogique gauche sur le boîtier de commande)
Espace Bouton A/Sélectionner
Entrez Bouton A/Sélectionner
Caractère d'échappement Bouton B/Précédent*

*Lorsque ni les événements KeyDown ni KeyUp du 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 au sein de l’application. Cependant, 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;
}

Notes

Si le bouton B est utilisé pour revenir en arrière, n’affichez pas de bouton Précédent dans l’interface utilisateur. Si vous utilisez une vue navigation, le bouton Précédent est masqué automatiquement. Pour plus d’informations sur la navigation descendante, consultez Historique de navigation et Navigation descendante pour les applications Windows.

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, voir CommandBar et ContextFlyout.

Prise en charge des boutons accélérateurs

Les boutons accélérateurs permettant d’accélérer la navigation dans une interface utilisateur. Cependant, ces boutons peuvent être propres à certains périphériques d’entrée ; certains utilisateurs ne seront donc pas en mesure d’utiliser ces fonctions. En fait, le boîtier de commande est actuellement le seul appareil d’entrée qui prend en charge les fonctions d’accélérateur pour les applications Windows sur Xbox One.

Le tableau suivant répertorie la prise en charge intégrée des accélérateurs dans l’UWP, en plus de ce que vous pouvez implémenter vous-même. Intégrez ces comportements à votre interface utilisateur personnalisée afin de proposer une expérience utilisateur cohérente et conviviale.

Interaction Clavier/souris Boîtier de commande Intégrée pour : Recommandée pour :
Page vers le haut/bas Page vers le haut/bas Gâchette gauche/droite CalendarView, ListBox, ListViewBase, ListView, ScrollViewer, Selector, LoopingSelector, ComboBox, FlipView Affichages qui prennent en charge le défilement vertical
Page vers la gauche/droite None Gâchettes hautes gauche/droite ListBox, ListViewBase, ListView, ScrollViewer, Selector, LoopingSelector, FlipView Affichages qui prennent en charge le défilement horizontal
Zoom avant/arrière Ctrl +/- Gâchette gauche/droite None ScrollViewer, les affichages qui prennent en charge le zoom avant et arrière
Ouvrir/fermer le volet de navigation None Affichage None Volets de navigation
Rechercher None Bouton Y None Raccourci pour la fonction de recherche principale dans l’application
Ouvrir le menu contextuel Cliquez avec le bouton droit sur Bouton Menu ContextFlyout Menu contextuels

Interaction et navigation en mode focus XY

Si votre application prend en charge une navigation en mode focus appropriée pour le clavier, cela conviendra également pour le boîtier de commande et la télécommande. La navigation avec les touches de direction est mappée au bouton multidirectionnel (ainsi qu’au stick analogique gauche sur le boîtier de commande), et l’interaction avec les éléments d’interface utilisateur est mappée à la touche Entrée/Sélectionner (voir Boîtier de commande et télécommande).

De nombreux événements et propriétés sont utilisés à la fois par le clavier et le boîtier de commande. Ils sont déclenchés KeyDown 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 des recommandations en matière de conception de clavier, voir Interactions avec le clavier.

Si la prise en charge du clavier est correctement implémentée, votre application fonctionnera assez bien ; toutefois, du travail supplémentaire peut être nécessaire pour la prise en charge de chaque scénario. Réfléchissez aux besoins spécifiques de votre application pour proposer une expérience utilisateur optimale.

Important

Le mode souris est activé par défaut pour les applications Windows s’exécutant sur Xbox One. Pour désactiver le mode souris et activer la navigation en mode focus XY, définissez Application.RequiresPointerMode=WhenRequested.

Débogage des problèmes de focus

La méthode FocusManager.GetFocusedElement vous indique sur quel élément le focus se trouve actuellement. Cela s’avère utile dans des situations où l’emplacement du focus visuel n’est pas clairement identifiable. Vous pouvez consigner les informations dans la fenêtre Sortie de Visual Studio :

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

La navigation en mode XY peut ne pas fonctionner comme prévu pour trois raisons courantes :

  • La valeur de la propriété IsTabStop ou Visibility est incorrecte.
  • Le contrôle qui obtient le focus 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 rend quelque chose d’intéressant.
  • Un contrôle focalisable se trouve au-dessus d’un autre. La navigation XY ne prend pas en charge les contrôles qui se chevauchent.

Si la navigation en mode XY ne fonctionne toujours pas après correction de ces problèmes courants, vous pouvez pointer manuellement vers l’élément sur lequel vous voulez un focus à l’aide de la méthode décrite dans Remplacement de la navigation par défaut.

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

  • Vous avez remodélisé le contrôle sans inclure de focus visuel. Définissez UseSystemFocusVisuals="True" ou ajoutez un focus visuel manuellement.
  • Vous avez déplacé le focus en appelant la méthode Focus(FocusState.Pointer). Le paramètre FocusState détermine ce qui se produit pour le focus visuel. En général, vous devez définir ce paramètre sur FocusState.Programmatic, ce qui maintient la visibilité du focus visuel si ce dernier était déjà visible, et le maintient masqué si c’était le cas précédemment.

Le reste de cette section décrit en détail les problèmes courants de conception lorsque la navigation en mode XY est utilisée, et propose plusieurs méthodes pour résoudre ces problèmes.

Interface utilisateur inaccessible

Étant donné que la navigation en mode focus XY limite le déplacement vers le haut, le bas, à gauche et à droite, il existe des scénarios où certaines parties de l’interface utilisateur ne sont pas accessibles. Le schéma suivant illustre un exemple du type de disposition d’interface utilisateur que la navigation en mode 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/télécommande dans la mesure où la navigation horizontale et la navigation verticale sont prioritaires ; l’élément du milieu ne sera jamais d’une priorité suffisamment élevée pour avoir le focus.

Éléments dans les quatre coins avec un élément inaccessible au milieu

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

Remplacement de la navigation par défaut

Si la plateforme Windows universelle tente de garantir la convivialité de la navigation par bouton multidirectionnel/stick analogique gauche, elle ne peut pas garantir un comportement optimisé pour les intentions de votre application. Pour vous assurer que la navigation est optimisée pour votre application, la meilleure solution consiste à la tester avec une manette de jeu et à vérifier que tous les éléments d’interface utilisateur sont accessibles par l’utilisateur, d’une manière qui soit pertinente pour les scénarios de votre application. Si les scénarios de votre application nécessitent un comportement ne pouvant être obtenu par le biais de la navigation en mode focus XY, envisagez de suivre les conseils indiqués dans les sections suivantes et/ou de remplacer le comportement afin de placer le focus sur un élément logique.

L’extrait de code suivant montre comment remplacer le comportement de navigation en mode 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 est sur le bouton Home et que l’utilisateur navigue vers la gauche, le focus se déplace sur le bouton MyBtnLeft ; si l’utilisateur navigue vers la droite, le focus se déplace sur le bouton MyBtnRight et ainsi de suite.

Pour empêcher le focus de se déplacer dans une certaine direction à partir d’un contrôle, utilisez la propriété XYFocus* pour pointer sur ce même contrôle :

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

Avec ces propriétés XYFocus, un parent de contrôle peut également forcer la navigation de ses enfants lorsque le candidat au focus suivant se trouve en dehors de son arborescence visuelle, à moins que l’enfant qui a le focus utilise la même propriété XYFocus.

<StackPanel Orientation="Horizontal" Margin="300,300">
    <UserControl XYFocusRight="{x:Bind ButtonThree}">
        <StackPanel>
            <Button Content="One"/>
            <Button Content="Two"/>
        </StackPanel>
    </UserControl>
    <StackPanel>
        <Button x:Name="ButtonThree" Content="Three"/>
        <Button Content="Four"/>
    </StackPanel>
</StackPanel>

Dans l’exemple ci-dessus, si le focus est sur l’objet Button Two et l’utilisateur navigue vers la droite, le meilleur candidat au focus est l’objet Button Four ; cependant, le focus est déplacé vers l’objet Button Three, car le parent UserControl l’oblige à naviguer vers celui-ci lorsqu’il se trouve en dehors de son arborescence visuelle.

Chemin nécessitant le moins de clics

Permettez à l’utilisateur d’effectuer les tâches les plus courantes avec le moins de clics possible. Dans l’exemple suivant, la classe TextBlock est placée entre le bouton Lecture (qui a initialement le focus) et un élément couramment utilisé ; un élément inutile est ainsi placé entre les tâches prioritaires.

Meilleures pratiques en matière de navigation nécessitant le moins de clics

Dans l’exemple suivant, la classe TextBlock est placée au-dessus du bouton Lecture à la place. Le simple fait de réorganiser 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.

TextBlock déplacée au-dessus du bouton de lecture afin qu’elle ne soit plus entre les tâches prioritaires

CommandBar et ContextFlyout

Lorsque vous utilisez une CommandBar, n’oubliez pas le problème de défilement dans une liste, comme mentionné dans Problème : Éléments d’interface utilisateur localisés suite à un long défilement dans une liste/grille. L’image suivante illustre une disposition d’interface utilisateur avec la CommandBar en bas d’une liste/grille. L’utilisateur devrait faire défiler toute la liste/grille pour atteindre la CommandBar.

CommandBar en bas de la liste/grille

Que se passe-t-il si vous placez le contrôle CommandBarau-dessus de la liste/grille ? Bien qu’un utilisateur ayant effectué un défilement vers le bas de la liste/grille doive en refaire un vers le haut pour atteindre le contrôle CommandBar, cette navigation est un peu plus courte que la configuration précédente. On suppose ici que le focus initial de votre application est placé à côté ou au-dessus de la CommandBar ; cette approche ne fonctionne pas aussi bien si le focus initial se trouve sous la liste/grille. Si ces éléments CommandBar sont des éléments d’action globale auxquels l’utilisateur n’accède que rarement (tels qu’un bouton Synchronisation), le fait de les disposer au-dessus de la liste/grille reste acceptable.

Bien qu’il soit impossible d’empiler les éléments d’une CommandBar verticalement, le fait de les placer en face du défilement (par exemple, à gauche ou à droite d’une liste avec défilement vertical, ou en haut ou en bas d’une liste avec défilement horizontal) constitue une autre option que vous devrez peut-être prendre en compte si elle fonctionne bien pour la disposition de votre interface utilisateur.

Si votre application dispose d’une CommandBar dont les éléments doivent être facilement accessibles aux utilisateurs, vous devrez peut-être les placer à l’intérieur d’un ContextFlyout et les supprimer de la CommandBar. ContextFlyout est une propriété de UIElement et est le menu contextuel associé à cet élément. Sur PC, lorsque cliquez à l’aide du bouton droit sur un élément avec un ContextFlyout, ce menu contextuel apparaît. Sur Xbox One, cela se produit lorsque vous appuyez sur le bouton Menu tandis que le focus se trouve sur un tel élément.

Défis en matière de disposition de l’interface utilisateur

Certaines dispositions d’interface utilisateur posent plus de défis en raison de la navigation en mode focus XY et doivent être évaluées au cas par cas. Bien qu’il n’existe pas de méthode « absolue » et que la solution que vous choisissez dépend des besoins spécifiques de votre application, certaines techniques permettent de créer une excellente expérience TV.

Pour mieux comprendre ce point, examinons un exemple d’application qui illustre certains de ces problèmes et les techniques permettant de les résoudre.

Notes

Cet exemple d’application sert à illustrer des problèmes d’interface utilisateur et leurs solutions potentielles, et ne vise pas à présenter la meilleure expérience utilisateur possible pour votre application.

Ce qui suit est un exemple d’application pour le secteur immobilier qui affiche une liste des maisons disponibles à la vente, une carte, la description des propriétés, ainsi que d’autres informations. Cette application pose trois défis que vous pouvez surmonter à l’aide des techniques suivantes :

Exemple d’application pour le secteur immobilier

Problème : Éléments d’interface utilisateur situés après une liste/grille à long défilement

La ListView des propriétés visibles dans l’image suivante est une très longue liste à faire défiler. Si l’activation n’est pas requise pour la ListView, le focus se place sur le premier élément de la liste lorsque l’utilisateur navigue vers cette dernière. L’utilisateur doit parcourir tous les éléments de la liste pour atteindre le bouton Précédent ou Suivant. Dans des cas comme celui-ci où l’utilisateur doit parcourir l’ensemble de 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.

Application pour le secteur immobilier : une liste comprenant 50 éléments nécessite 51 clics pour atteindre les boutons du bas.

Solutions

Réorganisation de l’interface utilisateur

À moins que le focus initial ne soit placé au bas de la page, les éléments d’interface utilisateur placés au-dessus d’une liste à long défilement sont en général plus facilement accessibles que s’ils étaient placés au-dessous. Si cette nouvelle disposition fonctionne pour d’autres appareils, il serait moins coûteux en ressources de modifier la disposition pour toutes les familles d’appareils au lieu d’apporter des modifications d’interface utilisateur spécifiques pour Xbox One. En outre, le fait de placer des éléments d’interface utilisateur à l’opposé du sens de défilement (autrement dit, horizontalement pour une liste à défilement vertical ou verticalement pour une liste à défilement horizontal) améliorera davantage l’accessibilité.

Application pour le secteur immobilier : Placement des boutons au-dessus d’une liste à long défilement

Focus sur l’engagement

Lorsqu’une activation est requise, la totalité de la ListView devient une cible du focus unique. L’utilisateur sera en mesure d’ignorer le contenu de la liste afin d’accéder au prochain élément pouvant être actif. Pour en savoir plus sur les contrôles prenant en charge l’activation et sur leur utilisation, consultez la section Activation du focus.

Application pour le secteur immobilier : définition de l’activation sur Requis pour atteindre les boutons Précédent/Suivant en un clic

Problème : ScrollViewer sans élément pouvant être actif

Étant donné que la navigation en mode focus XY dépend de la navigation vers un seul élément d’interface utilisateur pouvant être actif à la fois, un ScrollViewer ne contenant aucun élément pouvant être actif (par exemple, contenant seulement du texte), peut provoquer un scénario dans lequel l’utilisateur n’est pas en mesure d’afficher l’ensemble du contenu dans le ScrollViewer. Pour connaître les solutions de ce scénario et des scénarios connexes, voir Activation du focus.

Application pour le secteur immobilier : ScrollViewer contenant uniquement du texte

Problème : interface utilisateur à défilement libre

Si votre application nécessite une interface utilisateur à défilement libre, telle qu’une surface de dessin ou, dans l’exemple présent, une carte, la navigation en mode focus XY ne fonctionne 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.

Mapper un élément d’interface utilisateur à l’aide du mode souris

Mode de la souris

Comme décrit dans Interaction et navigation en mode focus XY, le focus est déplacé à l’aide du système de navigation XY sur Xbox One, ce qui permet à l’utilisateur de déplacer le focus entre les contrôles en effectuant des déplacements vers le haut, le bas, la gauche et la droite. Toutefois, certains contrôles comme WebView et MapControl nécessitent une interaction semblable à celle faite avec la souris, avec laquelle les utilisateurs peuvent déplacer le pointeur librement à l’intérieur des limites du contrôle. Certaines applications permettent également de déplacer le pointeur sur la page entière ; l’expérience boîtier de commande/télécommande est alors semblable à l’expérience souris sur PC.

Pour ces scénarios, demandez un pointeur (mode souris) pour la page entière, ou sur un contrôle à l’intérieur d’une page. Par exemple, votre application peut contenir une page comportant un contrôle WebView qui utilise le mode souris uniquement à l’intérieur du contrôle tandis que la navigation en mode focus XY est utilisée partout ailleurs. Pour demander un pointeur, vous pouvez spécifier si vous le voulez lorsqu’un contrôle ou une page sont actifs ou lorsqu’une page a le focus.

Notes

La demande de pointeur lorsqu’un contrôle a le focus n’est pas prise en charge.

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

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

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

Pour plus d’informations et des exemples de code HTML/JavaScript, consultez Comment désactiver le mode souris.

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

Mappages de bouton pour boîtier de commande/télécommande en mode souris

Notes

Le mode souris est uniquement pris en charge sur Xbox One avec boîtier de commande/télécommande. Il est ignoré sans avertissement dans d’autres familles d’appareils et types d’entrée.

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 (valeur par défaut), WhenEngagedet WhenFocused.

Activation du mode souris sur un contrôle

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

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

Notes

Si un contrôle active le mode souris lorsqu’il est employé, il doit également être employé avec IsEngagementRequired="true" ; sinon, le mode souris n’est pas activé.

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

En outre, le mode demandé d’un contrôle est examiné uniquement lorsqu’il a le focus ; le mode n’est pas changé dynamiquement tant qu’il a le focus.

Activation du mode souris dans une page

Lorsqu’une page dispose de la propriété RequiresPointer="WhenFocused", le mode souris est activé pour la page entière lorsqu’elle a le focus. L’extrait de code suivant illustre l’obtention de cette propriété par une page :

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

Notes

La valeur WhenFocused est uniquement prise en charge dans les objets Page. Une exception est levée si vous tentez de définir cette valeur sur un contrôle.

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

Lors de l’affichage de vidéos ou d’autres types de contenu en plein écran, il est généralement préférable de masquer le curseur, car celui-ci peut distraire l’utilisateur. Ce scénario se produit lorsque le reste de l’application utilise le mode souris, mais que vous souhaitez désactiver ce mode lors de l’affichage de contenu en plein écran. Pour ce faire, placez le contenu en plein écran dans son propre objet Page, puis suivez les étapes ci-dessous.

  1. Dans l’objet App, définissez RequiresPointerMode="WhenRequested".
  2. Dans chaque objet Page, excepté l’objet Page en plein écran, définissez RequiresPointer="WhenFocused".
  3. Pour l’objet Page en plein écran, définissez RequiresPointer="Never".

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

Visuel du focus

Le visuel du focus est le contour de l’élément de l’interface utilisateur sur lequel se trouve actuellement le focus. Cela permet de guider l’utilisateur pour une navigation facile dans votre interface utilisateur et sans se perdre.

Avec une mise à jour visuelle et de nombreuses options de personnalisation ajoutées au visuel focus, les développeurs peuvent être confiants 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 jeu/la télécommande.

Bien que le même visuel du focus puisse être utilisé sur différentes plateformes, le contexte diffère légèrement pour l’expérience « 10-foot ». Vous devez supposer que l’utilisateur ne se concentre pas sur l’ensemble de l’écran de TV. C’est pourquoi il est important que l’élément ayant actuellement le focus s’affiche toujours clairement à l’utilisateur ; cela évite la frustration de devoir rechercher les éléments visuels.

Il est également important de garder à l’esprit que le visuel du focus s’affiche par défaut lorsqu’un boîtier de commande ou une télécommande sont utilisés, mais pas un clavier. Il s’affiche donc lorsque vous exécutez votre application sur Xbox One, même si vous ne l’avez pas implémenté.

Placement initial du visuel du focus

Lors du lancement d’une application ou de la navigation vers une page, placez le focus sur un élément d’interface utilisateur approprié (le premier élément auquel l’utilisateur applique une action). Par exemple, une application de photos peut placer le focus sur le premier élément dans la galerie de photos, et une application de musique, dans laquelle l’utilisateur a ouvert une vue détaillée d’un morceau, peut placer le focus sur le bouton Lecture pour faciliter la lecture de la musique.

Essayez de placer le focus initial dans la zone 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 cet angle en premier car c’est à cet endroit que commence généralement le flux de contenu d’une application.

Rendre le focus clairement visible

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

Les expériences en plein écran, telles que la lecture de vidéos ou le visionnage de photos, pourraient constituer une exception à cette règle. Dans ces cas, l’affichage du focus visuel n’est pas approprié.

Effet Révéler focus

Révéler le focus est un effet d’éclairage qui anime la bordure des éléments pouvant être mis au point, tels qu’un bouton, lorsque l’utilisateur déplace la manette de jeu ou le focus clavier vers eux. En animant la lueur autour de la bordure des éléments ciblés, Révéler le focus permet aux utilisateurs de mieux comprendre où se trouve le focus et où le focus va.

Révéler que le focus est désactivé par défaut. Pour les expériences de 10 pieds, 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 conseils pour révéler le focus.

Personnaliser le focus visuel

Si vous souhaitez personnaliser le focus visuel, vous pouvez le faire en modifiant les propriétés relatives au focus visuel pour chaque contrôle. Vous pouvez tirer parti de plusieurs de ces propriétés afin de personnaliser votre application.

Vous pouvez même désactiver le focus visuel fourni par le système en dessinant votre propre focus visuel à l’aide des états visuels. Pour en savoir plus, voir VisualState.

Superposition de l’abandon interactif

Pour attirer l’attention de l’utilisateur sur les éléments de l’interface utilisateur que l’utilisateur manipule actuellement avec la manette 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 est un élément à prendre en compte lors de la conception de votre interface utilisateur. Vous pouvez définir la propriété LightDismissOverlayMode sur un FlyoutBase quelconque pour activer ou désactiver la couche de fumée ; la valeur par défaut est Auto, ce qui signifie qu’elle est activée sur Xbox et désactivée ailleurs. Pour plus d’informations, voir Boîte de dialogue modale et abandon interactif.

Activation du focus

L’activation du focus est conçue pour faciliter l’utilisation d’une manette de jeu ou d’une télécommande pour interagir avec une application.

Notes

La définition de l’activation du focus n’affecte pas le clavier ou les autres périphériques d’entrée.

Lorsque la propriété IsFocusEngagementEnabled d’un objet FrameworkElement est définie sur True, elle signale le contrôle comme nécessitant l’activation du focus. Cela signifie que l’utilisateur doit appuyer sur le bouton A/Sélectionner pour activer le contrôle et interagir avec ce dernier. Lorsqu’il a terminé, l’utilisateur peut appuyer sur le bouton B/Précédent pour désactiver le contrôle et naviguer hors de ce dernier.

Notes

IsFocusEngagementEnabled est une nouvelle API qui n’est pas encore documentée.

Interruption du focus

L’interruption du focus survient lorsqu’un utilisateur tente d’accéder à l’interface utilisateur d’une application, mais la navigation est « interrompue » au sein d’un contrôle, rendant difficile, voire impossible, le déplacement en dehors de ce contrôle.

L’exemple suivant montre une interface utilisateur provoquant l’interruption du focus.

Boutons à gauche et à droite d’un curseur horizontal

Si l’utilisateur veut accéder au bouton droit à partir du bouton gauche, il serait logique de supposer que la seule action requise serait d’appuyer deux fois sur le bouton multidirectionnel/stick analogique gauche. Toutefois, si le Slider ne nécessite pas d’activation, le comportement suivant se produit : lorsque l’utilisateur appuie à droite pour la première fois, le focus est décalé vers le Slider ; lorsqu’il réappuie à droite, la poignée du Slider se déplace à droite. L’utilisateur continuerait de déplacer la poignée vers la droite sans toutefois réussir à atteindre le bouton.

Plusieurs approches existent pour contourner ce problème. L’une consiste à concevoir une disposition différente, comme dans l’exemple d’application pour le secteur immobilier dans Interaction et navigation en mode focus XY, où nous avons déplacé les boutons Précédent et Suivant au-dessus de ListView. L’empilement vertical (et non horizontal) des contrôles, comme le montre l’image suivante, peut résoudre le problème.

Boutons au-dessus et en dessous d’un curseur horizontal

À présent, l’utilisateur peut accéder à chaque contrôle en appuyant sur les boutons haut et bas sur le bouton multidirectionnel/stick analogique gauche. Lorsque le Slider a le focus, l’utilisateur peut appuyer sur le bouton gauche/droite pour déplacer la poignée du Slider, comme prévu.

Une autre approche pour résoudre ce problème consiste à demander une activation du Slider. Si vous définissez IsFocusEngagementEnabled="True", cela se traduit par le comportement suivant.

Nécessité d’activation du focus sur un curseur afin que l’utilisateur puisse accéder au bouton situé à droite

Lorsque le Slider nécessite une activation du focus, l’utilisateur peut accéder au bouton situé à droite en appuyant simplement deux fois à droite sur le bouton multidirectionnel/stick analogique 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 que vous souhaiterez peut-être activer :

Contrairement au contrôle Slider, ces contrôles n’interrompent pas le focus en leur sein ; cependant, ils peuvent poser des problèmes en matière de facilité d’utilisation s’ils contiennent de grandes quantités de données. Voici un exemple d’un contrôle ListView qui contient une grande quantité de données.

Contrôle ListView avec une grande quantité de données et des boutons au-dessus et en dessous

Comme pour l’exemple Slider, nous allons essayer de naviguer à partir du bouton du haut vers le bouton du bas avec un boîtier de commande/une télécommande. En partant du bouton du haut, où se trouve le focus, le fait d’appuyer sur la flèche Bas sur le bouton multidirectionnel/stick analogique gauche déplace le focus sur le premier élément dans le contrôle ListView (« Item 1 »). Lorsque l’utilisateur appuie à nouveau, le focus est déplacé sur l’élément suivant dans la liste, et non sur le bouton situé en bas. Pour accéder au bouton du bas, l’utilisateur doit d’abord parcourir chaque élément du contrôle ListView. Si le contrôle ListView contient une grande quantité de données, cela peut s’avérer peu pratique et dégrader l’expérience utilisateur.

Pour résoudre ce problème, définissez la propriété IsFocusEngagementEnabled="True" sur ListView pour demander son activation. Cela permet à l’utilisateur de traverser rapidement le contrôle ListView en appuyant simplement sur le bouton Bas. Néanmoins, l’utilisateur n’est pas en mesure de parcourir la liste ou de sélectionner un élément dans celle-ci, sauf s’il l’active en appuyant sur le bouton A/Sélectionner lorsqu’il a le focus, puis en appuyant sur le bouton B/Précédent pour le désactiver.

Contrôle ListView avec activation requise

ScrollViewer

Le contrôle ScrollViewer, qui possède des caractéristiques particulières, diffère légèrement des contrôles précédents. Si vous disposez d’un ScrollViewer avec du contenu pouvant être actif, par défaut, la navigation vers ScrollViewer vous permet de parcourir ses éléments pouvant être actifs. Comme pour un contrôle ListView, vous devez parcourir chaque élément pour naviguer en dehors du contrôle ScrollViewer.

Si le n’a pas de contenu pouvant être concentré (par exemple, s’il contient uniquement du ScrollViewer texte), vous pouvez définir IsFocusEngagementEnabled="True" pour que l’utilisateur puisse engager le à l’aide ScrollViewer du bouton A/Sélectionner. Une fois activé, l’utilisateur peut faire défiler le texte à l’aide du bouton multidirectionnel/stick analogique gauche, puis appuyer sur le bouton B/Précédent pour le désactiver.

Une autre approche consiste à définir IsTabStop="True" sur le ScrollViewer afin que l’utilisateur n’ait pas besoin d’engager le contrôle : il peut simplement placer le focus sur celui-ci, puis faire défiler à l’aide du D-pad/stick gauche lorsqu’il n’y a aucun élément focalisable dans le ScrollViewer.

Paramètres par défaut de l’activation du focus

Certains contrôles provoquent une interruption du focus assez fréquente pour justifier une activation du focus pour leurs paramètres par défaut. D’autres ont désactivé cette fonction par défaut, mais peuvent tirer profit de son activation. Le tableau suivant répertorie ces contrôles et leurs comportements d’activation du focus par défaut.

Control Paramètre par défaut de l’activation du focus
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 aucun changement comportemental ou visuel lorsque 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 plusieurs appareils, à la fois dans des expériences 2 pieds et 10 pieds, et quelle que soit la capacité de l’appareil d’entrée ou de l’utilisateur. L’utilisation des recommandations de cet article peut garantir que votre application est aussi bonne qu’elle peut l’être sur le téléviseur et un PC.