Un système animé et dynamique, première partie : utilisation des vignettes, des badges et des toasts

Les vignettes dynamiques et les fonctionnalités associées (badges, notifications toast et notifications Push) font partie des éléments les plus caractéristiques de Windows 8 et des applications du Windows Store. Elles se combinent les unes aux autres pour créer un « système animé et dynamique » : les applications reçoivent en permanence des flux d'informations issus de leurs services, visibles à la fois sur l'écran d'accueil et sur l'écran de verrouillage, mêmes lorsqu'elles ne sont pas en cours d'exécution.

Dans de précédents billets publiés sur ce blog, nous avons déjà abordé quelques-uns des principaux aspects des vignettes dynamiques et des notifications.

Pour rappel :

• Création d'une expérience utilisateur optimale en matière de vignettes (première partie) : ce billet explique comment concevoir une vignette et choisir un modèle basé sur la fonction première de l'application.
• Création d'une expérience utilisateur optimale en matière de vignettes (deuxième partie) : ce billet décrit comment une application envoie des mises à jour locales, met en place des notifications périodiques et gère les vignettes secondaires. Il présente également la structure des services, aussi bien pour PHP que pour ASP.NET.

Pour prolonger les informations figurant dans ces ressources, ce billet en trois parties aborde de façon plus approfondie plusieurs domaines.

Voici les thèmes abordés dans la première partie (ce billet) :

• Courte présentation en images de l'expérience utilisateur : que signifie ce « système animé et dynamique » pour l'utilisateur ?
• Schéma XML des vignettes, des badges, et des notifications toast, qui présente différentes fonctionnalités et caractéristiques qui ne sont pas forcément évidentes au vu des catalogues de modèles.
• Relation entre les vignettes, les notifications et les tâches d'arrière-plan.

Dans la deuxième partie, nous aborderons le développement et le débogage des services dans plusieurs langues. Nous utiliserons en particulier localhost et Visual Studio 2012 Express for Web/Visual Studio 2012. La deuxième partie abordera aussi l'utilisation des services mobiles Windows Azure, également dans le cadre du développement et du débogage.

La troisième partie portera quant à elle sur les notifications Push. Nous verrons notamment comment utiliser les Services de notifications Push Windows (WNS) ainsi que les services mobiles Windows Azure pour prendre en charge les notifications Push dans les applications.

Ces trois parties s'inscrivent dans le prolongement la présentation que j'ai animée au cours de la conférence //Build 2012, intitulée 3-101 Alive With Activity, et dont vous trouverez la vidéo et les diapositives sur le site Channel 9. Elles prolongent également les ressources du Chapitre 13 de mon livre électronique gratuit publié par Microsoft Press, Programming Windows 8 Apps in HTML, CSS, and JavaScript (malgré son titre, il peut également être utile aux développeurs travaillant avec d'autres langages).

Que signifie ce « système animé et dynamique » pour l'utilisateur ?

Le « système animé et dynamique » que nous évoquons dans cette série de billets est visible à trois endroits du système : dans l'écran d'accueil, dans l'écran de verrouillage et partout où des notifications toast sont susceptibles de s'afficher.

En ce qui concerne l'écran d'accueil, vous connaissez maintenant très bien le concept de vignette. Comme le montrent les exemples ci-dessous, les vignettes peuvent être carrées ou rectangulaires. Leur disposition est très variable, puisqu'il est possible d'afficher du texte, des images ou les deux à la fois. Les couleurs sont définies par le manifeste de l'application. L'utilisateur peut choisir le format de la vignette (carré ou rectangulaire), à condition toutefois que l'application prenne en charge les deux formats. La partie inférieure gauche de la vignette peut afficher le nom de l'application, un logo ou rien du tout. La partie inférieure droite peut contenir un petit badge, c'est-à-dire un nombre compris entre 1 et 99 (pour les courriers électroniques, les messages instantanés, etc.) ou l'un des glyphes prédéfinis (pour en savoir plus, consultez le Catalogue des images de badges).

Les modèles de vignettes intègrent également différentes présentations de type « aperçu », qui alternent entre une partie du contenu (une image, par exemple) et une deuxième partie, par exemple du texte (dans le Catalogue de modèles de vignette, ces modèles ressemblent à des vignettes deux fois plus hautes que la normale, parce que les deux moitiés sont affichées l'une au-dessus de l'autre). Le système anime les transitions entre ces deux parties, en parfaite harmonie avec les autres animations appliquées aux vignettes. Par ailleurs, chaque vignette peut posséder une file d'attente contenant jusqu'à cinq mises à jour cycliques, qui sont à leur tour animées par le système en coordination avec d'autres vignettes. Chaque mise à jour présente en file d'attente peut posséder une balise qui vous permet de les remplacer de façon individuelle. Dans le cas contraire, la file d'attente est traitée dans l'ordre d'arrivée.

Cette coordination entre les animations explique en partie pourquoi Windows limite les mises à jour des vignettes à un ensemble de modèles prédéfinis. Imaginez ce que serait l'expérience utilisateur de l'écran d'accueil si les applications pouvaient afficher absolument tout et n'importe quoi sur leurs vignettes. Si Windows offrait la liberté de lire des vidéos sur les vignettes, l'autonomie de la batterie diminuerait bien plus vite, par exemple, mais surtout l'écran d'accueil deviendrait véritablement anarchique. Alors oui, nous aurions là l'exact opposé d'un écran d'accueil entièrement statique, mais ce ne serait certainement pas beau à voir ! Les concepteurs de Windows souhaitaient mettre à votre disposition un écran d'accueil plaisant à regarder sur une longue durée. C'est pourquoi ils ont mis au point une expérience utilisateur animée et dynamique, mais qui respire l'unité et l'harmonie entre toutes les vignettes. L'utilisation de modèles et d'animations contrôlées par le système entraîne une certaine uniformité, mais autorise des variations significatives d'une application à l'autre. (Par ailleurs, n'oubliez pas que vous pouvez toujours utiliser un modèle contenant uniquement une image et y insérer ainsi la présentation que vous souhaitez. Évitez toutefois de créer des images contenant des boutons suggérant la possibilité de réaliser différentes actions à partir de différentes zones de la vignette, ce qui est techniquement impossible.)

Les notifications toast apparaissent par-dessus l'écran d'accueil, l'écran de verrouillage, le Bureau ou toute autre application en cours d'exécution. En appuyant sur une notification toast, vous activez l'application correspondante, en fonction des arguments spécifiés au moment de l'émission du toast. Les toasts s'affichent dans la couleur définie par le manifeste de l'application concernée et contiennent le logo de l'application (en bas à droite). La couleur et le logo facilitent l'identification de l'application, qui est activée dès que l'utilisateur appuie sur le toast.

Comme pour les vignettes, la disposition de chaque toast est définie par un modèle issu du Catalogue de modèles de toast, qui offre différentes possibilités de présentation (texte uniquement ou texte+image). Les toasts s'affichent pendant une durée bien précise, puis disparaissent progressivement de l'écran. Elles peuvent être accompagnées d'un son et être répétées, comme pour des rappels de rendez-vous.

Dans l'écran de verrouillage, l'activité des applications s'affiche aux côtés de la date, de l'heure et des badges système. Comme dans l'exemple ci-dessous, une application peut afficher jusqu'à sept logos et badges en bas de la vignette et une mise à jour textuelle située près de l'heure :

L'utilisateur contrôle les informations affichées sur l'écran de verrouillage par le biais du menu Paramètres du PC > Personnaliser > Écran de verrouillage (voir l'exemple ci-dessous). Sur la première ligne, le fait d'appuyer sur l'un des carrés affiche une liste d'applications compatibles avec l'écran de verrouillage, présentées au moyen d'un logo et d'un badge. Sur la deuxième ligne, vous pouvez choisir l'application chargée de fournir le texte détaillé. Ce texte provient plus précisément de la dernière mise à jour de la vignette de l'application correspondante.

Code XML des mises à jour

Maintenant que nous savons ce qui se passe côté utilisateur en matière d'animations, une question se pose : en quoi consistent exactement ces mises à jour ? En d'autres termes, à quoi correspond une mise à jour de vignette, un badge ou une notification toast ?

Dans tous les cas, à l'exception des notifications brutes, les mises à jour sont de simples fragments de code XML que Windows peut traiter pour mettre à jour une vignette ou afficher un toast. (Les notifications brutes contiennent du texte ou des données binaires propres à l'application. Les applications et les tâches d'arrière-plan qui reçoivent ces notifications traitent en général ces données elles-mêmes et génèrent des mises à jour de vignette ou de badge, ou des toasts.)

Les modèles précédemment mentionnés ne sont en fait que de simples structures XML bien précises destinées à accueillir ces mises à jour. Par exemple, une mise à jour de badge pour le numéro 7 ressemble à ceci :

 <badge value="7"/>

Nous appelons souvent ces fragments de code XML des charges utiles. En voici une similaire, correspondant au badge représentant un point rouge, situé dans la vignette centrale du bas sur la première image de ce billet :

 <badge value="busy"/>

La charge utile XML de cette même vignette rectangulaire, qui inclut une référence à son image, au texte et aux options de logo/nom, ressemblerait plus ou moins à l'extrait de code ci-dessous (l'URI de l'image est fictif), qui utilise le modèle TileWideSmallImageAndText01 :

 <tile>
  <visual>
    <binding template="TileWideSmallImageAndText01" branding="logo">
      <image id="1" src="https://friends.contoso.com/sally.png" alt="Sally's picture"/>
      <text id="1">Hey, you there? Txt me when you’re back</text>
    </binding>
  </visual>
</tile>

Dans cette charge utile, vous pouvez constater que nous identifions le modèle par le biais de l'élément binding. Windows valide le reste du code XML par rapport à ce modèle. L'attribut branding de l'élément binding indique s'il faut afficher le logo, le nom de l'application (name) ou ni l'un ni l'autre (none). Les éléments enfants de binding décrivent ensuite les autres parties requises du modèle.

Plus que les modèles spécifiques de ces mises à jour, il est intéressant d'étudier le schéma général de leur code XML, car celui-ci révèle d'autres fonctionnalités qui peuvent être exploitées avec chaque mise à jour. En effet, le Catalogue de modèles de vignette, le Catalogue des images de badges et le Catalogue de modèles de toast indiquent uniquement les éléments obligatoires. Le schéma, de son côté, montre toutes les options supplémentaires.

Les schémas sont décrits dans la section de la documentation consacrée aux schémas des vignettes, des toasts et des badges. Cependant, les informations détaillées étant éparpillées dans de nombreux sujets, je vais les regrouper ici dans un pseudo-schéma qui nous permet d'examiner les structures dans leur ensemble.

Commençons par les mises à jour de badge, qui sont les plus simples :

 <?xml version="1.0" encoding="utf-8" ?>
<badge value = "1-99" | "none" | "activity" | "alert" | “attention” | "available" |
    "away" | "busy" | "newMessage" | "paused" | "playing" | "unavailable" | "error" 
    version? = "integer" />

D'un point de vue technique, toutes les charges utiles XML doivent contenir la balise d'en-tête <?xml> . Windows fonctionne correctement sans cette balise, mais pour plus d'exhaustivité, je préfère l'inclure.

Vous remarquez ensuite que l'élément badge contient uniquement un attribut value, qui peut être un nombre (toutes les valeurs supérieures à 99 s'affichent sous la forme « 99+ ») ou l'un des mots prédéfinis qui identifient des glyphes spécifiques. Ceux-ci sont également décrits dans la page Catalogue des images de badges de la documentation.

Le seul autre attribut présent est l'attribut facultatif version (le ? situé après le nom indique qu'il est facultatif), ce qui permet de modifier le schéma par la suite. Celui-ci étant facultatif, vous pouvez l'omettre dans vos charges utiles pour le moment.

Les mises à jour de vignette possèdent le pseudo-schéma suivant :

 <?xml version="1.0" encoding="utf-8" ?>
<tile>
  <visual version? = "integer" lang? = "string" baseUri? = "anyURI" fallback? = "string"
    branding? = "none" | "logo" | "name" addImageQuery? = "boolean" >

    <!-- One or more binding elements -->
    <binding template = "TileSquareImage" | "TileSquareBlock" | "TileSquareText01" | ... 
      fallback? = "string" lang? = "string" baseUri? = "anyURI"
      branding? = "none" addImageQuery? = "boolean" >
      
      <!-- Some combination of image and text elements -->
      <image id = "integer" src = "string" alt? = "string" addImageQuery? = "boolean" />
      <text id = "integer" lang? = "string" />
    </binding>
  </visual>
</tile>

Dans l'élément visual, qui contient des attributs qui s'appliquent à l'intégralité de la mise à jour, se trouve l'attribut facultatif version, que vous pouvez également omettre pour le moment. Voici la liste des autres attributs :

Dans l'élément visual, la charge utile possède ensuite un ou plusieurs éléments binding : un pour chaque taille de vignette. Ainsi, une même charge de travail peut contenir (ou doit contenir, dans l'idéal) une mise à jour pour les vignettes carrées et rectangulaires. Ces informations sont importantes, car l'utilisateur peut modifier la taille de la vignette à tout moment. Si vous omettez une des tailles, la mise à jour ne s'affichera pas si l'utilisateur a choisi d'afficher la vignette à cette taille. Sachez cependant que vous pouvez envoyer des mises à jour séparées pour chaque taille : dans ce cas, Windows conserve les deux mises à jour.

Dans l'élément binding, vous pouvez constater que template identifie le modèle XML à valider. Les mêmes attributs que ceux de visual sont également présents, mais ils s'appliquent uniquement aux éléments figurant dans binding (et sont donc prioritaires sur ceux de visual). L'autre attribut est fallback, qui identifie le modèle à utiliser si le modèle principal est introuvable. Cet attribut permettra d'assurer une compatibilité descendante dans les futures versions de Windows et n'est donc d'aucune utilité avec Windows 8.

Chaque binding contient une combinaison d'éléments image et text, selon le modèle utilisé. Les attributs de ces éléments sont suffisamment explicites ou ont déjà été abordés. Comme vous pouvez vous y attendre, les attributs des éléments image et text qui figurent également dans binding ou visual remplacent les valeurs des mêmes attributs figurant dans les éléments parents.

Pour les notifications toast, la structure est similaire à celle des vignettes, mais offre des fonctionnalités supplémentaires :

 <toast launch? = "string" duration? = "long" | "short" >
  <visual version? = "integer" lang? = "string"
    baseUri? = "anyURI" branding? = "none" | "name" | "logo" addImageQuery? = "boolean" >

    <!-- One or more bindings -->
    <binding template  = "ToastImageAndText01" | "ToastImageAndText02" | ...=""
      fallback? = "string"  lang? = "string" baseUri? = "anyURI"
      branding? = "none" addImageQuery? = "boolean" >

      <!-- Some number of child elements -->
      <image id  = "integer" src = "string" alt = "string" addImageQuery? = "boolean" />
      <text id = "integer" lang? = "string" />
    </binding>
  </visual>

  <!-- Optional audio -->
  <audio src? = "ms-winsoundevent:Notification.Default" | ...=""
    loop? = "boolean" silent? = "boolean" />
</toast>

L'ensemble des attributs lang, baseUri, branding et addImageQuery de visual ont la même signification et les mêmes valeurs par défaut que pour les vignettes, tout comme les attributs des attributs binding, image et text. Dans cette partie de la charge de travail, la seule différence entre une mise à jour de vignette et une notification toast réside dans les modèles pris en charge.

La particularité de la charge de travail d'un toast réside dans les attributs de l'élément toast situé le plus à l'extérieur et dans son enfant facultatif audio.

Avec toast, il est possible d'affecter à l'attribut launch une chaîne qui sera transmise sous forme d'arguments au gestionnaire d'activation de l'application, comme avec une vignette secondaire. L'attribut duration peut prendre la valeur « short »(cinq secondes ou la valeur définie dans Paramètres du PC > Options d'ergonomie) ou « long » (25 secondes ou la valeur définie dans Paramètres du PC > Options d'ergonomie, la plus longue des deux étant prise en compte).

Dans audio, l'attribut src est une chaîne indiquant un son parmi les sons prédéfinis disponibles dans le Catalogue d'options audio de toast. Pour le moment, le choix se limite à ces sons, qui sont généralement associés aux sons système configurés dans le Panneau de configuration. (Remarque : si vous désactivez tous les sons, comme j'ai l'habitude de le faire, vous n'entendrez rien... Pensez-y lorsque vous testez votre application !) Cette limitation s'explique par plusieurs raisons. Ainsi, le fait d'inclure des sons personnalisés à partir d'une source distante générerait beaucoup plus de trafic réseau, ce qui pourrait vite devenir un problème lorsque l'appareil affiche l'écran de verrouillage et essaie d'économiser de l'énergie en mode de veille connectée. Elle empêche également certains abus : les toasts pourraient par exemple être utilisés pour diffuser des publicités sonores.

Par ailleurs, si la valeur de l'attribut silent est « true », le son de l'appareil est systématiquement coupé. Comme pour loop, si l'attribut duration du toast est défini et que vous configurez src sur l'un des quatre sons « looping » du catalogue (deux variations pour « Alarm » et deux autres pour « Call »), vous pouvez également configurer loop sur la valeur « true » pour répéter le son ou sur la valeur « false » pour lire le son une seule fois (valeur par défaut).

En dehors de la lecture audio en boucle, il est également possible de planifier un toast déclenché à intervalle régulier. Ce comportement ne fait pas partie de la charge utile XML : en effet, vous l'activez lors de la création de l'objet ScheduledToastNotification. Dans ces cas, la même charge utile (son et autres informations) est affichée à chaque intervalle.

Un système animé sans applications en cours d'exécution

Une fois que vous savez quels types de mises à jour seront générés par quelles charges utiles XML, vous devez étudier comment ces charges utiles sont transmises au système à l'heure adéquate et comment elles sont créées. Nous avons déjà évoqué ces deux sujets dans de précédents billets, Création d'une expérience utilisateur optimale en matière de vignettes (première partie) et Création d'une expérience utilisateur optimale en matière de vignettes (deuxième partie), qui montrent comment générer les charges utiles dans le code. Pour cela, nous utilisons la bibliothèque NotificationsExtensions, qui est incluse dans différents exemples et est également disponible par le biais de Visual Studio sous forme de package NuGet.

Essayons de récapituler les méthodes permettant de fournir ces charges utiles. Trois moyens sont à notre disposition :

1. Une application en cours d'exécution ou une tâche d'arrière-plan d'application peuvent émettre des mises à jour directes ou des mises à jour locales. Celles-ci peuvent être immédiates ou être programmées à une heure ultérieure. Les vignettes, les badges et les toasts peuvent également avoir une heure d'expiration, à laquelle elles sont automatiquement supprimées ou retirées du calendrier, si elles n'ont pas encore été livrées.

2. Une application en cours d'exécution peut transmettre à Windows jusqu'à cinq URI pour les mises à jour périodiques et spécifier des intervalles compris entre 30 minutes et un jour. (Lorsque plusieurs URI sont utilisés, chacun d'entre eux correspond à l'un des cinq emplacements de la file d'attente des mises à jour.) Dès lors qu'une mise à jour périodique a été configurée, Windows envoie une requête (HTTP GET) à cet URI, à chaque intervalle. Si Windows reçoit en retour une charge utile valide, il envoie la mise à jour à la vignette adéquate de la part de l'application, exactement comme si elle avait été émise directement par l'application elle-même. Nous expliquerons comment créer des services de mise à jour dans la deuxième partie de cette série.

   Les mises à jour périodiques offrent un avantage majeur : les requêtes continuent même si l'application n'est pas en cours d'exécution, ce qui permet à la vignette de recevoir des mises à jour et des badges en continu, sans que l'utilisateur soit obligé d'ouvrir l'application. Bien évidemment, j'espère que vos mises à jour sont suffisamment intéressantes pour inciter l'utilisateur à utiliser le plus souvent possible votre application !

3. Une application peut demander un URI de canal de notifications Push Windows (WNS) et envoyer cet URI à ses propres services principaux. Ces services peuvent ensuite émettre des mises à jour de toutes sortes via WNS, à travers cet URI de canal. À son tour, WNS envoie la mise à jour à l'appareil concerné lorsqu'il est connecté. Windows reçoit les mises à jour et les applique à la vignette adéquate ou affiche le toast. Une autre solution existe : une application peut configurer une tâche d'arrière-plan de façon à recevoir ces notifications Push (cette tâche est requise pour les notifications brutes). Nous aborderons les notifications Push dans la troisième partie de cette série de billets.

Le tableau ci-dessous résume les options et fournit des informations sur la fonctionnalité de file d'attente cyclique des vignettes, ainsi que sur les fonctionnalités de récurrence et de son des toasts :

Il est important de remarquer que toutes les informations de ce billet relatives aux vignettes et aux badges s'appliquent aussi bien à la vignette principale d'une application qu'aux vignettes secondaires. Les billets de blog mentionnés ci-dessus fournissent des informations complémentaires sur les vignettes secondaires. Pour en savoir plus, vous pouvez également consulter l'exemple de vignettes secondaires.

Puisque nous évoquons les exemples, sachez aussi que l'exemple de vignettes et de badges d'application, l'exemple de notifications planifiées et l'exemple de notifications Push et de notifications périodiques côté client sont à votre disposition pour découvrir différents scénarios. Dès lors que vous vous intéressez aux vignettes et aux notifications dans votre application, nous vous recommandons de vous familiariser avec le code détaillé dans ces exemples.

Rappelez-vous également que les mises à jour de vignette, de badge et de toast peuvent être générées à partir de tâches d'arrière-plan. De mon point de vue, les tâches d'arrière-plan constituent une sorte de code d'application qui est exécuté même lorsque l'application elle-même est suspendue, voire totalement absente de la mémoire. L'émission d'une mise à jour à partir d'une tâche d'arrière-plan utilise le même code que l'application principale et il n'y a donc aucune différence véritable à signaler.

Les tâches d'arrière-plan sont idéales pour vérifier l'état de diverses conditions. Cette opération peut être effectuée rapidement et respecte ainsi les quotas de charge processeur consommés par ces tâches. Lorsque les conditions l'exigent, la tâche d'arrière-plan peut générer une notification appropriée. En effet, le rôle principal d'une tâche d'arrière-plan est (a) d'émettre les mises à jour ou (b) d'enregistrer des valeurs dans les dossiers AppData de l'application ou dans le conteneur de paramètres que l'application traitera lors de sa prochaine exécution.

Les tâches d'arrière-plan sont également essentielles dans le cadre du traitement des notifications Push brutes lorsque l'application n'est pas en cours d'exécution, mais nous y reviendrons également dans la troisième partie.

Pour plus d'informations sur les tâches d'arrière-plan, consultez le billet précédemment publié sur ce blog intitulé Rester productif lorsque votre application n'est pas à l'écran : tâches en arrière-plan, ainsi que la présentation plus générale Rester productif lorsque votre application n'est pas à l'écran.

Forts de ces informations, nous sommes maintenant prêts à quitter le confort familier des applications clients pour étudier le rôle des services en ligne et ce qu'ils apportent à vos vignettes, vos badges et vos toasts. Nous aborderons ce sujet dans les deuxième et troisième parties.

Kraig Brockschmidt

Chef de projet, équipe Écosystème Windows

Auteur de Programming Windows 8 Apps in HTML, CSS, and JavaScript