Navigation, orientation et mouvements (applications du Windows Phone Store)

Les applications Windows Phone reposent sur un modèle qui permet à l’utilisateur de naviguer d’une vue de contenu à l’autre à l’aide de liens et de revenir en arrière à l’aide du bouton Précédent matériel. L’objectif de ce modèle est de faciliter la création d’applications basées sur des vues qui s’intègrent naturellement au modèle de navigation parmi les pages Windows Phone.

Pages et cadres

Le modèle de navigation parmi les pages est un système de Hub et Spoke. Cela signifie que l’utilisateur doit utiliser le bouton Précédent pour revenir à une page qu’il a affichée (sauf si vous ajoutez explicitement des liens vers des pages dans votre application). Ce comportement s’apparente à la façon dont un navigateur Web affiche et parcourt l’historique des pages Web.

Le système effectue le suivi de chaque page qu’un utilisateur a visitée et la place dans la « pile arrière » ; ainsi, quand l’utilisateur appuie sur le bouton Précédent, la dernière page enregistrée dans la pile arrière est affichée. Le nombre de pages pouvant être placées dans la pile arrière est illimité.

Par exemple, si un utilisateur navigue depuis la page 1 (p1) vers successivement la page 2 (p2), p1, p2, la page 3 (p3) et p1, il crée la pile arrière p1, p2, p1, p2, p3, p1. Si l’utilisateur a changé le contenu de la seconde instance de p2 dans la pile arrière, mais qu’il revient en arrière à l’aide du bouton Précédent jusqu’à la première instance de p2 dans la pile arrière, les modifications antérieures n’apparaissent pas dans cette page, sauf si la page actualise les données ; la vue est une capture instantanée de cette page telle qu’elle se présentait à l’utilisateur à ce stade de la navigation.

Remarque importante: Soyez attentif si vous implémentez des liens ou des boutons de navigation d’une page à une autre qui pourraient avoir une incidence sur la façon dont l’utilisateur navigue dans l’application, et déterminez si une page doit être actualisée quand l’utilisateur y accède.

Les définitions suivantes s’appliquent dans le contexte du modèle de page d’application pour Windows Phone :

  • Page : collection d’état persistant reconnaissable par l’utilisateur. Il peut s’agir d’une page contenant des informations, d’un contenu à mémoriser ou de liens vers d’autres pages.
  • Écran : écran d’interface utilisateur général tel qu’une fenêtre contextuelle, une boîte de dialogue ou un écran de démarrage qui ne contient pas de contenu à mémoriser. Il ne s’agit pas d’une collection d’état persistant reconnaissable par l’utilisateur.

La figure suivante illustre une structure d’application hypothétique composée de pages et d’écrans.

Exemple de structure de l’application

Exemple de structure de l’application

À propos des pages

Une application peut comprendre les pages suivantes :

  • Page d’accueil
  • Page de widgets
  • Page de détails de widgets (contenant les Pivots)
  • Page de détails des gadgets
  • Page de recherche
  • Page de paramètres

L’écran de démarrage et l’écran de connexion ne sont pas des pages, car d’après la définition indiquée plus haut, une page est une collection d’état persistant reconnaissable par l’utilisateur ; les écrans de démarrage sont simplement utilisés comme espace réservé avant que votre application ne soit démarrée. Pour plus d’informations sur les écrans de démarrage, voir Graphismes, indicateurs visuels et notifications essentiels pour Windows Phone.

En règle générale, un écran de connexion ne contient pas de données d’état, car son rôle se limite à recueillir des informations d’identification (toutefois, il en va différemment si vous décidez de mémoriser le dernier nom d’utilisateur entré).

Remarque importante: Toutes les vues dans Windows Phone ne nécessitent pas une page.

Pour déterminer si votre interface utilisateur doit être une page, posez-vous les questions suivantes :

  • L’utilisateur souhaiterait-il explicitement visiter la page ?
  • L’utilisateur se souviendrait-il d’être passé par la page et souhaiterait-il y revenir ?

Les pages des applications se composent de sections de contenu discrètes et s’affichent en tant qu’écrans distincts. Vous pouvez créer autant de pages que nécessaire et construire leur interface utilisateur pour présenter le contenu d’une application, puis fournir une navigation vers ces pages depuis le cadre ou la page si vous le souhaitez. Une seule page peut suffire pour une application simple, tandis que de nombreuses pages peuvent s’avérer nécessaires pour une application plus complexe.

Mode plein écran

Vous pouvez également implémenter un mode plein écran dans lequel la barre d’état ou la barre d’application inférieure peut éventuellement être affichée, mais vous devez définir ce comportement de manière explicite à l’aide de la propriété de visibilité, car, par défaut, ces barres n’apparaissent pas. La meilleure pratique pour un mode plein écran consiste à n’afficher aucune des deux barres pour que l’utilisateur se concentre sur l’expérience liée au contenu. Les notifications et les appels entrants sont toujours affichés en mode plein écran, même si la barre d’état et/ou la barre de l’application sont masquées. Pour plus d’informations sur la barre d’état et la barre de l’application, voir Graphismes, indicateurs visuels et notifications essentiels pour Windows Phone.

Remarque  En mode plein écran, l’utilisateur n’a pas accès à l’horloge. Nous vous conseillons de n’utiliser le mode plein écran que si le contenu le nécessite.

Dans Windows Phone, la navigation peut être définie comme étant une transition entre les pages.

Toutefois, toutes les étapes de transition ne sont pas considérées comme une navigation à part entière, telles que le passage de l’écran de démarrage à la page d’accueil. Le fait de quitter un écran qui n’est pas une page est assimilable à une transition.

La section suivante indique les meilleures pratiques pour utiliser un modèle de page efficace.

Écrans et transitions non liées à une navigation

Pour l’interface utilisateur temporaire, comme l’écran de connexion, vous pouvez, à l’aide du contrôle Popup ou du contrôle de menu volant, afficher un contenu qui recouvre partiellement l’écran sans implémenter d’écrans distincts qui nécessiteraient une navigation complète. Vous pouvez ajouter l’événement BackKeyPress à votre code et définir e.Cancel sur true quand la fenêtre contextuelle est visible pour permettre à l’utilisateur de fermer la boîte de dialogue en appuyant sur le bouton Précédent.

Plusieurs vues de contenu

Dans le cas des pages qui affichent plusieurs sections de contenu, pour passer d’un contenu à un autre sans utiliser de navigation, reliez simplement les contrôles de votre page à une nouvelle propriété DataContext. En outre, vous pouvez effectuer la reliaison en chargeant plusieurs instances d’un objet UserControl dans la page ou en utilisant tout autre mécanisme pour afficher un nouveau contenu. Vous pouvez choisir la façon dont l’utilisateur passe d’un élément à l’autre et revient en arrière. Par exemple, vous pouvez envisager d’utiliser les boutons de barre d’application Précédent et Suivant. Toutefois, nous vous conseillons de ne pas abuser du Bouton Précédent pour les transitions locales.

Enregistrement de l’état et désactivation

Vous pouvez enregistrer un historique local des transitions qui se produisent dans une page donnée pour que l’utilisateur puisse retracer ses étapes si une application est désactivée. Dans le cas des scénarios simples tels que ceux qui utilisent la navigation vers l’arrière ou vers l’avant, il vous suffit d’enregistrer l’état de la page. En utilisant parallèlement la classe Frame, vous devriez obtenir toutes les informations nécessaires pour explorer l’ensemble de données après un état désactivé. Dans le cas des applications dont l’historique des transitions locales est plus complexe, comme la navigation libre entre des éléments liés, vous pouvez choisir de stocker une partie de cet historique dans l’état de page, en veillant toutefois à limiter raisonnablement les éléments à stocker. Il est essentiel que l’utilisateur recoure au bouton Précédent matériel et revienne à la page précédente au lieu de retourner à l’élément précédemment affiché.

Le tableau suivant fournit des informations sur les parties courantes d’une application considérées comme des pages.

Type d’écran Page Description
Écran de démarrage Non Partie temporaire de l’expérience de démarrage, vers laquelle l’utilisateur ne peut pas naviguer.
Expérience du Hub Oui Approche d’écran d’accueil courante pour les applications Windows Phone.
Page de détails Oui Cette page est courante pour les applications centrées sur les données et paramétrées par l’intermédiaire de la chaîne de requête.
Élément pivot Non Un élément pivot est un composant plus petit du contrôle pivot qui constitue un emplacement approprié pour le contenu.
Boîte de dialogue de connexion ou d’erreur Non Il s’agit d’une interface utilisateur temporaire déclenchée par l’état de l’application, vers laquelle l’utilisateur ne navigue pas directement.
Énumération d’élément Non Permet de parcourir du contenu similaire dans le cadre d’une activité sur place et non comme moyen de navigation.

 

Le tableau suivant récapitule les approches que vous pouvez adopter vis-à-vis des différents types d’implémentation d’élément d’interface utilisateur.

Type d’élément d’interface utilisateur Implémentation Comportement du Bouton Précédent Comportement de l’élément résiduel
Page Page Le Bouton Précédent permet de revenir en arrière ou de quitter l’application automatiquement. Votre application ne doit gérer que les situations de perte de données. Demeure automatiquement sur la pile arrière.
Interface utilisateur temporaire Fenêtre contextuelle ou fenêtre enfant L’application doit prendre en charge l’annulation de la fenêtre contextuelle. Le clavier visuel et les boîtes de dialogue de message s’annulent automatiquement quand l’utilisateur appuie sur le Bouton Précédent. L’application doit annuler ou faire disparaître la fenêtre contextuelle pendant la navigation.
Énumération d’élément UserControl Non applicable : hébergé dans une page parente. L’application doit enregistrer l’élément actif de manière appropriée.

 

Importance des orientations et des axes

Les utilisateurs de la plateforme Windows Phone s’attendent à ce que certaines applications, notamment celles qui présentent de la vidéo, des cartes ou des éléments de jeu, fonctionnent en orientation portrait et en orientation paysage. Pour plus d’informations sur l’orientation, voir la section « Orientations de l’écran » dans Découverte de Windows Phone.

En outre, ils s’attendent à ce que la navigation fonctionne le long des axes X et Y, et apprécient la sensation de pouvoir rechercher du nouveau contenu en effectuant des mouvements de balayage sur l’écran du téléphone, tant latéraux que du bord supérieur vers le bord inférieur. Concevez votre application de telle sorte qu’elle puisse exploiter l’orientation et les axes.

Quand vous concevez une application qui peut s’exécuter en orientation paysage :

  • Déterminez si votre application doit pouvoir s’exécuter également en mode portrait et si elle aura une seule orientation statique.
  • L’orientation paysage est utile quand les utilisateurs souhaitent optimiser l’espace horizontal de l’écran. Vous pouvez réorganiser les contrôles ou la disposition quand l’utilisateur oriente différemment le téléphone, pour renforcer l’impression que l’écran peut alors accueillir davantage de contenu horizontalement.
  • L’orientation paysage est souvent utilisée pour présenter un contenu multimédia, car elle correspond aux proportions classiques. Si la vocation première du mode paysage de votre application est la consommation de contenu, faites disparaître en fondu les contrôles et la navigation pour enrichir l’expérience de l’affichage.

Entrées tactiles

Les entrées tactiles constituent la principale méthode dont dispose un utilisateur pour interagir avec l’interface utilisateur de Windows Phone. Dans Windows Phone, une entrée tactile se caractérise par l’appui ou le balayage d’un ou de plusieurs doigts sur un écran tactile.

Les contrôles fournis dans le Kit de développement logiciel (SDK) de Windows Phone sont utilisés en tant qu’éléments d’interaction tactile. Pour qu’ils puissent remplir leur rôle d’interaction tactile, ces éléments doivent toujours être correctement dimensionnés. Pour plus d’informations sur les cibles tactiles, voir Interactions et facilité d’utilisation avec Windows Phone.

Les entrées tactiles à point unique et multipoint suivantes sont prises en charge dans Windows Phone :

Entrées tactiles à point unique

  • Appui
  • Double appui
  • Mouvement panoramique
  • Raccourci
  • Maintien appuyé

Entrée tactile multipoint

  • Pincement et étirement

Appui

Un appui est un contact unique et bref avec l’écran dans une zone délimitée.

Appui

Appui

Deux comportements sont associés à un appui :

  • Le fait de poser le doigt marque le début d’un événement tactile.
  • Le fait de le relever exécute l’action associée à cet événement.

En outre, un appui atténue totalement l’inertie d’un mouvement éventuellement en cours.

Double appui

Un double appui se caractérise par deux appuis rapides dans une zone délimitée.

Double appui

Double appui

Un double appui permet de basculer entre les états zoom avant et zoom arrière d’un contrôle ou d’une application. Le zoom appliqué par l’application dépend de l’état actuel. L’application définit les états zoom avant et zoom arrière.

Mouvement panoramique

Effectuer un mouvement panoramique consiste à poser un doigt sur l’écran, puis à le déplacer dans une direction. Le mouvement panoramique prend fin quand le doigt est relevé de l’écran.

Mouvement panoramique

Mouvement panoramique

Deux comportements sont associés à un mouvement panoramique :

  • Déplacement d’un contenu par le biais d’une manipulation directe. Le contenu demeure en contact avec le doigt et suit le déplacement de ce dernier. Les contrôles ou l’application peuvent déterminer la direction à prendre en charge pour le mouvement panoramique. Ce déplacement peut être horizontal, vertical ou peut être toute autre direction spécifiée. Si le contenu est déplacé vers un état intermédiaire, il doit retrouver l’état le plus proche.
  • Déplacement ou réorganisation d’un élément spécifique. L’élément suit le doigt, puis se positionne au nouvel emplacement quand le doigt est relevé de l’écran.

Raccourci

Effectuer un raccourci consiste à toucher l’écran avec un doigt, à déplacer le doigt rapidement dans une direction, puis à le relever de l’écran alors qu’il est toujours en mouvement. Un raccourci peut suivre un mouvement panoramique.

Raccourci

Raccourci

Un mouvement de raccourci permet de faire défiler une zone, ou de déplacer un objet, avec inertie. Les contrôles ou l’application peuvent être configurés pour prendre en charge un comportement de raccourci directionnel spécifique. Il peut s’agir d’un chemin horizontal, vertical ou d’une autre direction spécifiée. Si un chemin horizontal ou vertical est spécifié, les déplacements dans les autres directions sont convertis en déplacement vertical ou horizontal.

En règle générale, un raccourci déplace la totalité du canevas, mais vous pouvez spécifier des objets spécifiques à la place.

Pincement et étirement

Effectuer un pincement et étirement consiste à placer deux doigts dans des zones délimitées distinctes, puis à rapprocher les doigts (pincement) ou à les éloigner (étirement).

Pincement et étirement

Pincement et étirement

Un pincement et étirement permet d’effectuer un zoom continu dont l’origine est le milieu de la ligne fictive formée par les deux doigts. Si un pincement ou un étirement prend fin avec des raccourcis, votre application peut, si vous le souhaitez, répondre par un zoom avec inertie.

Maintien appuyé

Effectuer un maintien appuyé consiste à placer un doigt dans une zone délimitée pendant une période définie. L’entrée maintien appuyé est généralement réservée à l’affichage d’un menu contextuel ou d’une page d’options associés à un élément.

Maintien appuyé

Maintien appuyé

Points d’entrée tactile multiples

Windows Phone prend en charge au moins quatre points d’entrée tactile utilisateur simultanés pour permettre des interactions uniques avec l’application. Les jeux ou les applications d’instruments de musique en sont de simples exemples.

Les zones d’écran tactiles dont le diamètre est supérieur ou égal à 7 mm sont traitées comme des zones tactiles uniques si la distance entre leurs bords est supérieure ou égale à 3,5 mm, et tous les mouvements sont pris en charge.

En outre, comme chaque point d’entrée tactile entraîne une charge supplémentaire pour le processeur, l’implémentation de plus de deux points d’entrée tactile simultanés risque d’avoir une incidence sur les performances. Bien que Windows Phone prenne en charge jusqu’à 10 points d’entrée tactile, tous les écrans matériels ne prennent pas en charge plus de quatre points d’entrée tactile.

Rubriques connexes

Navigation dans l’application pour Windows Phone

Comment mettre en place la navigation entre les pages sur Windows Phone

Démarrage rapide : entrée tactile pour Windows Phone

Prise en charge des mouvements pour Windows Phone