Recommandations en matière de vignettes et de badges

Applies to Windows and Windows Phone

Description

Cette rubrique décrit les meilleures pratiques et les recommandations en matière de globalisation/localisation pour créer et mettre à jour la vignette de votre application, à la fois sur l’écran d’accueil et sur l’écran de verrouillage. En outre, elle dresse la liste de toutes les conditions requises particulières en matière de vignettes pour que votre application soit acceptée dans le Windows Store.

Voir cette fonctionnalité appliquée dans notre série Fonctionnalités d’application de A à Z:  Interface utilisateur des applications du Windows Store de A à Z

Pratiques conseillées et déconseillées

Recommandations générales

  • Utilisez uniquement une petite et une moyenne vignette si votre application n’utilise pas de notifications par vignette pour envoyer des mises à jour à l’utilisateur. Le contenu d’une grande vignette large doit toujours être « dynamique » et mis à jour régulièrement. Si vous n’utilisez pas de vignette dynamique, ne spécifiez pas de grand logo ou de logo large dans le manifeste.
  • Utilisez uniquement une petite ou une grande vignette avec un badge si votre application ne prend en charge que les scénarios avec des courtes notifications — en d’autres termes, les notifications qui ne peuvent être exprimées qu’à l’aide d’une badge image ou d’un numéro unique. Par exemple, une application SMS qui prévoit d’utiliser les notifications pour communiquer uniquement le nombre de nouveaux messages texte reçus correspond à ce scénario. Ne spécifiez pas un logo large dans le manifeste.
  • Utilisez uniquement la petite et la moyenne taille si votre application envoie des mises à jour qui ne doivent pas s’afficher en détail sur l’écran d’accueil. Par exemple, une application de bulletin de paie peut simplement indiquer qu’un nouveau bulletin de paie est disponible en omettant des détails comme son montant. Ne spécifiez pas un grand logo ou un logo large dans le manifeste.
  • Utilisez la grande vignette ou la vignette large si votre application comporte un contenu nouveau et intéressant à présenter aux utilisateurs et si ces notifications sont régulièrement mises à jour (au moins une fois par semaine).
  • La grande vignette sert à afficher plusieurs articles avec une seule notification par vignette sur une vignette, des listes d’éléments plus longues, ou des images que l’utilisateur aimerait voir dans une taille plus grande sur l’écran d’accueil.
  • Utilisez l’image de vignette par défaut pour représenter la marque de votre application, essentiellement sous forme de Canvas pour le logo de l’application.
  • N’utilisez pas de vignettes dynamiques si vous n’avez pas de contenu intéressant, nouveau ou personnalisé à proposer à l’utilisateur. Une application de type calculatrice, par exemple, ne convient pas pour cet usage.
  • N’utilisez pas de vignettes dynamiques si la seule chose intéressante à communiquer est le dernier état de l’utilisateur. Les applications utilitaires, les outils de développement tels que Microsoft Visual Studio et les navigateurs qui affichent uniquement les miniatures de la dernière session de l’utilisateur ne doivent pas utiliser de vignettes dynamiques.
  • N’utilisez pas les vignettes dynamiques pour solliciter inutilement l’utilisateur ou afficher des publicités. Cela entraînerait votre exclusion du Windows Store.
  • N’utilisez pas la personnalisation pour l’un des éléments de la file d’attente de notifications ou pour l’un des cadres d’un modèle synoptique. Ces deux scénarios impliquent des modifications animées de la vignette, ce qui attire l’attention de l’utilisateur. Le fait d’attirer l’attention de l’utilisateur via une animation, juste pour afficher votre personnalisation au lieu d’un nouveau contenu pertinent, représente surtout une gêne pour l’utilisateur.

Vignettes par défaut

  • Si vous incluez un logo large ou des logos à la fois grands et larges, réfléchissez bien à la relation de conception entre les moyennes ou les grandes images et les images larges de vignette fournies. N’oubliez jamais que l’utilisateur peut afficher votre vignette dans toutes les tailles prises en charge et qu’il peut changer la taille choisie à tout moment. Voici quelques règles générales :
    • Centrez le logo horizontalement dans la vignette.
    • Gardez la même position verticale du logo dans la vignette carrée et la vignette large, dont les hauteurs sont identiques. Conservez la même position verticale proportionnelle du logo dans la grande vignette.
    • Incluez le nom de l’application au bas de la vignette si votre image de logo ne l’inclut pas. Mais souvenez-vous que la petite vignette ne permet pas d’afficher le nom de l’application. Les exemples suivants illustrent les deux situations.

      Vignettes qui utilisent l’élément du nom d’application défini dans le manifeste :

      Moyenne vignette et vignette large, toutes les deux utilisant le nom de l’application.

      Vignettes qui incluent le nom de l’application dans le logo :

      Moyenne vignette et vignette large avec une image qui inclut le nom de l’application.

    • Pour les applications ayant des noms longs qui tiennent sur deux lignes, vérifiez que votre logo et le nom ne se chevauchent pas. Il est préférable de limiter la taille de votre logo à environ 80 x 80 pixels dans la ressource d’image à 100 % pour la moyenne vignette et la vignette large.
    • Si vous rendez transparent l’espace autour du logo dans votre image, les couleurs de la marque (déclarées dans le manifeste) de votre application s’affichent dans un dégradé appliqué au préalable dans le cadre de l’apparence de Windows 8. Cette méthode est à utiliser avec un logo tel que la vignette d’application de messagerie illustrée précédemment.
  • Ne concevez pas la vignette par défaut en incluant un appel de texte explicite pour lancer l’application. Par exemple, ne concevez pas une vignette sur laquelle figure la phrase « Cliquez sur moi ! ».
  • Si votre logo contient le nom de l’application, ne répétez pas ce nom dans le champ du nom. Utilisez l’un ou l’autre, comme indiqué ici :

    Moyenne vignette qui utilise le champ du nom et vignette large qui inclut le nom de l’application dans le logo.

Modèles synoptiques

  • Utilisez des modèles synoptiques si votre scénario comprend des contenus sous forme d’image et de texte qui peuvent fonctionner de manière autonome. Par exemple, vous pouvez afficher la photo d’un lieu de vacances en haut du modèle et le nom de l’endroit en bas.
  • Un modèle synoptique attire l’attention de l’utilisateur quand il s’anime. Par conséquent, assurez-vous qu’il présente un contenu digne d’intérêt. Sinon, vous risquez fortement d’ennuyer l’utilisateur.
  • Lorsque vous utilisez un modèle synoptique, son affichage peut démarrer de part et d’autre (du cadre) de son cycle — texte complètement décalé vers le bas ou texte complètement décalé vers le haut — et s’animer en haut ou en bas vers l’autre cadre. Par conséquent, vous devez veiller à ce que le contenu de chacun des cadres soit autonome.
  • N’utilisez pas de modèles synoptiques pour afficher des informations déjà connues de l’utilisateur. Par exemple, une notification vidéo en pause sur une vignette ne doit pas utiliser un modèle synoptique.
  • N’utilisez pas de modèles synoptiques pour les notifications qui ne sont pas regroupées de manière conceptuelle. Par exemple, n’utilisez pas de modèles synoptiques si la photo n’a aucun rapport avec le texte.
  • N’utilisez pas de modèles synoptiques si la partie la plus importante de votre notification peut sortir de l’écran en raison de l’animation du modèle. Par exemple, pour une application météo qui affiche la température et une image d’accompagnement (un soleil souriant ou un nuage), l’utilisation d’un modèle synoptique risque de masquer la température (point important de la notification) à certains moments. Un modèle statique qui montre l’image et la température en même temps est plus utile à l’utilisateur.
  • N’utilisez pas de modèles synoptiques lorsque du texte est nécessaire pour fournir du contexte à l’image, comme dans un article de presse.

Badges

  • Utilisez la moyenne vignette avec un badge si votre application prend uniquement en charge les scénarios avec des notifications courtes. Par exemple, l’application SMS (Short Message Service) qui prévoit d’afficher uniquement le nombre de nouveaux messages texte reçus. Souvenez-vous, même si l’utilisateur redimensionne la vignette en petite taille, les badges sont toujours visibles.
  • Affichez un nombre sur le badge lorsque ce nombre est suffisamment faible pour être significatif dans votre scénario. S’il y a des chances que le badge affiche toujours le nombre 50 ou un nombre supérieur, envisagez plutôt d’utiliser un glyphe système. L’une des stratégies qui permettent de rendre le numéro de badge moins important consiste à afficher le compteur depuis le dernier lancement de l’application par l’utilisateur plutôt que le compteur absolu. Par exemple, il est plus utile d’afficher le nombre d’appels manqués depuis le dernier lancement de l’application par l’utilisateur que d’afficher le nombre total d’appels manqués depuis l’installation de l’application.
  • Utilisez l’un des glyphes système fournis pour indiquer une modification si un nombre est inutile ou trop important. Par exemple, le nombre de nouveaux articles non lus dans un flux RSS de grand volume peut être trop important. Dans ce cas, il est préférable d’utiliser le glyphe système newMessage.
  • Utilisez un glyphe si un nombre n’est pas significatif. Par exemple, si la vignette affiche la notification « en pause » pour une sélection, elle doit utiliser le glyphe paused car, dans ce cas, l’affichage d’un nombre n’a aucun sens.
  • Utilisez le glyphe newMessage dans le cas où un nombre est ambigu. Par exemple, le nombre « 10 » dans le badge de vignette d’un réseau social peut signifier 10 nouvelles demandes, 10 nouveaux messages, 10 nouvelles notifications, ou une combinaison des trois.
  • Utilisez le glyphe newMessage dans des scénarios impliquant un volume élevé, tels que le courrier ou un réseau social, dans lesquels le badge de vignette risque d’afficher en permanence la valeur maximale « 99+ ». Cela peut paraître un peu pesant pour l’utilisateur de toujours voir la valeur maximale affichée, laquelle ne transmet aucune information importante dans la mesure où elle est constante.
  • Ne répétez pas les numéros de badge au sein du contenu d’un corps de vignette volumineux, car les deux instances risquent d’être décalées.
  • N’utilisez pas un glyphe si ce qu’indique ce glyphe à l’utilisateur ne changera jamais. Les glyphes représentent des notifications et un état transitoire, et non une sorte de marque ou d’état permanent.

Notifications par vignette

  • Utilisez les informations dont vous disposez au sujet des utilisateurs pour leur envoyer des notifications personnalisées par le biais de la vignette. Les notifications par vignette doivent être pertinentes pour les utilisateurs. Les informations dont vous disposez sont en grande partie internes à votre application et peuvent être restreintes par les options de confidentialité choisies par l’utilisateur. Par exemple, un service de diffusion en continu télévisuelle peut afficher les mises à jour des informations d’un utilisateur concernant le programme qu’il regarde le plus souvent, ou une application de condition de trafic peut utiliser l’emplacement actuel de l’utilisateur (avec son accord) pour afficher la carte la plus pertinente pour ce dernier.
  • Envoyez des mises à jour fréquentes à la vignette pour donner à l’utilisateur l’impression que l’application est connectée et qu’elle reçoit du contenu actualisé, en direct. La fréquence des notifications par vignette doit dépendre de votre scénario d’application spécifique. Par exemple, une application de réseau social massivement utilisée peut se mettre à jour toutes les 15 minutes, une application de météorologie toutes les deux heures, une application d’information plusieurs fois par jour, une application d’offres commerciales une fois par jour et une application de magazine une fois par mois. Si votre application est planifiée pour se mettre à jour une fois par semaine, utilisez une moyenne vignette simple avec un badge pour éviter l’affichage du contenu obsolète.
  • Créez des notifications par vignette attrayantes et pertinentes pour permettre aux utilisateurs de décider s’ils doivent lancer votre application. En général, une notification invite l’utilisateur à lancer l’application pour obtenir des détails supplémentaires ou pour effectuer une action. Par exemple, une notification peut amener l’utilisateur à répondre à une publication au sein de médias sociaux, lire un article de presse complet ou obtenir les détails d’une vente.
  • Envoyez des notifications relatives au contenu hébergé sur la page d’accueil ou la page d’arrivée de votre application. Ainsi, lorsque l’utilisateur lance votre application en réponse à votre notification, il peut facilement trouver le contenu correspondant à la notification.

Indications d’utilisation supplémentaires

Une vignette est la représentation d’une application dans l’écran d’accueil. Elle vous permet de présenter du contenu riche et attrayant dans l’écran d’accueil lorsque votre application n’est pas en cours d’exécution. Le fait d’appuyer ou de cliquer sur la vignette lance l’application. Les vignettes sont carrées et de trois tailles (petite, moyenne et grande) ou larges (taille unique). Plusieurs variations sont fournies pour les modèles de taille moyenne et grande ainsi que pour le modèle large. Elles comportent du texte, des images ou une combinaison des deux. Certains modèles, appelés modèles synoptiques, se composent de deux cadres l’un au-dessus de l’autre qui s’affichent à tour de rôle dans l’espace de la vignette. Les modèles synoptiques sont disponibles pour la moyenne vignette et la vignette large.

Les vignettes peuvent être dynamiques (mises à jour à l’aide de notifications) ou statiques. Les vignettes sont créées en fonction d’une vignette par défaut, laquelle est définie dans le manifeste de l’application. Une vignette statique affiche toujours le contenu par défaut, qui est généralement une image de logo de la taille de la vignette. Une vignette dynamique peut mettre à jour la vignette par défaut afin d’afficher du nouveau contenu. Toutefois, elle peut revenir à sa valeur par défaut si la mise à jour expire ou est supprimée. Une vignette peut également afficher un badge d’état, sous la forme d’un numéro ou d’un glyphe.

Une moyenne ou grande vignette ou une vignette large peut éventuellement afficher une marque dans l’un des angles inférieurs, sous la forme du nom de l’application (sur une vignette dynamique ou par défaut) ou d’une petite icône (uniquement sur des vignettes dynamiques).

Deux points très importants sont à garder en mémoire :

  • L’utilisateur peut redimensionner la vignette dans toutes les tailles prises en charge. Vous n’avez aucun moyen de savoir quelle taille s’affiche actuellement sur l’écran d’accueil d’un utilisateur. Toutes les vignettes doivent prendre en charge la petite et la moyenne taille, mais éventuellement aussi la grande taille et la taille large. Notez que la prise en charge de la grande vignette nécessite également celle de la vignette large et implique donc la prise en charge des quatre tailles de vignettes. Les vignettes grandes et larges doivent être utilisées uniquement quand votre vignette prend en charge les mises à jour dynamiques.
  • Si votre vignette prend en charge les vignettes dynamiques, l’utilisateur peut désactiver et activer les notifications par vignette à tout moment. Quand les notifications par vignette sont désactivées, la vignette est statique.

Philosophie en matière de conception de vignette

Votre objectif consiste à créer une vignette attrayante pour votre application. Si vous utilisez une vignette dynamique, votre objectif est de présenter du nouveau contenu intéressant qui encouragera l’utilisateur à lancer l’application. À cette fin, évitez d’abuser des couleurs chargées. Les vignettes simples, nettes et élégantes ont plus de succès que celles qui attirent l’attention de manière exagérée.

Lors de la conception de votre application, vous vous demanderez peut-être : « Pourquoi devrais-je investir dans une vignette dynamique ? ». Voici quelques bonnes raisons :

  • Les vignettes sont la « porte d’entrée » de votre application. Une vignette dynamique élégante peut attirer les utilisateurs vers l’application lorsqu’elle n’est pas en cours d’exécution. Un utilisateur accorde une valeur croissante à une application qu’il utilise fréquemment.
  • Une vignette dynamique est un argument commercial qui différencie votre application des autres applications dans le Windows Store (les utilisateurs préfèreront probablement une application avec une belle vignette dynamique plutôt qu’une application similaire avec une vignette statique) et des applications sur d’autres systèmes d’exploitation qui n’autorisent que les vignettes et icônes statiques dans leur écran d’accueil.
  • Si les utilisateurs apprécient votre vignette dynamique, un positionnement proéminent de cette vignette dans l’écran d’accueil les encouragera à y revenir. La découverte inattendue de contenu intéressant dans l’application par le biais de la vignette contente les utilisateurs.
  • Avec la vignette dynamique, l’utilisateur est davantage enclin à épingler votre application de l’affichage Applications à l’écran d’accueil pour suivre les mises à jour en direct.
  • Si les utilisateurs n’apprécient pas votre vignette, ils risquent de la placer à la fin de l’écran d’accueil, d’annuler son ancrage, de désactiver les mises à jour ou même de désinstaller votre application.

Voici quelques-unes des caractéristiques qui rendent une vignette dynamique attrayante :

  • Contenu récent et fréquemment mis à jour qui fait sentir aux utilisateurs que votre application est active même lorsqu’elle ne s’exécute pas.

    Exemple : afficher les titres des actualités ou le nombre de nouveaux messages électroniques.

  • Mises à jour personnalisées qui utilisent ce que vous savez de l’utilisateur, tel que les centres d’intérêt qu’il peut spécifier dans les paramètres de l’application.

    Exemple : promotions du jour adaptées aux passe-temps de l’utilisateur.

  • Contenu pertinent au contexte actuel de l’utilisateur.

    Exemple : application relative aux conditions de circulation qui utilise l’emplacement actuel de l’utilisateur pour afficher un plan de circulation pertinent.

Choix parmi les différentes tailles de vignette

Votre application a toujours une petite ou une moyenne vignette. Vous devez fournir au moins une ressource d’image de moyenne vignette dans le manifeste de votre application. Vous pouvez aussi proposer une ressource pour la petite vignette, mais si vous ne le faites, l’utilisateur peut se servir d’une version mise à l’échelle inférieure.

Vous devez décider si vous souhaitez autoriser également une grande vignette ou une vignette large.

  • Pour la prise en charge d’une vignette large (310x150), ajoutez une image de logo large à votre vignette par défaut dans le manifeste de votre application. Si vous n’incluez pas cette image de logo large par défaut, votre vignette prend uniquement en charge la petite taille (carré de 70x70) et la moyenne taille (carré de 150x150). L’utilisateur ne peut pas la redimensionner en taille large et elle n’accepte pas les notifications larges.
  • Pour la prise en charge d’une grande vignette (carré de 310x310), ajoutez une grande image de logo et une image large de logo à votre vignette par défaut dans le manifeste de votre application. Si vous n’ajoutez pas une grande image de logo par défaut, l’utilisateur ne peut pas redimensionner votre vignette en grande taille et elle n’accepte pas les notifications qui ont recours aux grands modèles. Ajouter une grande image de logo par défaut sans inclure une image de logo large par défaut revient à les omettre toutes les deux car la prise en charge de la grande vignette implique la prise en charge de la vignette large.

Pour augmenter le nombre de tailles de vignettes prises en charge, vous devez publier une nouvelle version de votre application avec un manifeste mis à jour qui comprend les images de logo supplémentaires par défaut.

  • Les moyennes vignettes affichent moins de contenu que les grandes vignettes ou les vignettes larges. Choisissez donc soigneusement leur contenu. N’essayez pas de faire tenir tout le contenu d’une vignette large dans une moyenne vignette. Encore plus petites, les notifications par badge sont le seul contenu dynamique pris en charge par la petite vignette.

    Vignette large avec image et message texte en regard d’une moyenne vignette avec message texte partiel

    Si vous avez un contenu pour vignette large qui se compose d’une image et de texte, vous pouvez utiliser un modèle synoptique carré pour scinder le contenu en deux cadres. Cependant, n’utilisez pas un modèle synoptique si l’image elle-même n’est pas suffisante pour décrire l’essentiel de l’article.

Les notifications doivent fournir le contenu du modèle pour toutes les tailles de vignette prises en charge sauf la petite vignette, car la taille actuelle de la vignette est inconnue. Si une notification est définie à l’aide d’un modèle large uniquement pour une vignette de taille moyenne, ou si une notification est définie à l’aide d’un modèle de taille moyenne uniquement pour une vignette large, la notification ne sera pas visible.

Utilisation des vignettes par défaut

La vignette par défaut d’une application est définie dans son manifeste. Elle est statique et généralement de conception simple. Pour certaines applications, la vignette par défaut est tout ce dont vous avez besoin. Si un utilisateur épingle une vignette de l’affichage Applications à l’écran d’accueil une fois l’application installée, la vignette par défaut est affichée sur l’écran d’accueil jusqu’à ce qu’elle reçoive une notification. Si vous avez fourni une image de logo large, vous pouvez spécifier si la vignette est épinglée à l’écran d’accueil en tant que moyenne vignette ou vignette large. Par défaut, une vignette d’application est épinglée sous la forme d’une vignette large, si la taille de la vignette large est prise en charge par l’application via une image de logo large indiquée dans le manifeste ; dans le cas contraire, la vignette est épinglée en taille moyenne. Une fois épinglée, l’utilisateur peut redimensionner la vignette en utilisant toutes les tailles prises en charge. Une vignette dynamique peut retrouver sa taille par défaut si elle n’a pas de notifications à afficher.

Utilisation de modèles synoptiques

Les modèles synoptiques fournissent un contenu de vignette qui affiche à tour de rôle deux cadres d’informations dans l’espace de la vignette. Le cadre supérieur correspond à une image ou une collection d’images, alors que le cadre inférieur correspond à du texte ou du texte avec une image. Pour obtenir des exemples, voir le catalogue de modèles de vignette.

Autres remarques sur la conception

  • Lorsque vous réfléchissez à la manière de transmettre les informations de personnalisation de l’application dans une vignette, choisissez le nom de l’application, comme indiqué ici :

    Vignette utilisant un nom d’application

    ou un logo, comme indiqué ici :

    Vignette utilisant un logo d’application

    Ces éléments sont définis à l’origine dans le manifeste de l’application. Le développeur peut choisir celui qui doit être affiché dans chaque notification ultérieure. En revanche, une fois le choix du nom ou du logo arrêté, vous devez le conserver pour garantir la cohérence de l’application. Notez qu’en raison des limitations d’espace, certains modèles ne vous permettent pas d’afficher le nom — vous ne pouvez qu’afficher ou masquer le logo.

  • N’utilisez pas les éléments de type texte ou image pour afficher les informations de personnalisation d’une application dans une notification par vignette. Pour renforcer la personnalisation de votre application et garantir une certaine cohérence à l’utilisateur, la personnalisation doit être fournie par le biais des éléments de modèle prévus à cet effet : nom de l’application (nom court) ou image du logo. Une vignette dynamique peut considérablement modifier son apparence d’une notification à l’autre, mais l’emplacement du nom/logo doit être cohérent. Cela permet aux utilisateurs de trouver rapidement leurs applications favorites, car ils voient les informations au même endroit sur chaque vignette. Si votre application ne tire pas parti des éléments de personnalisation fournis (nom et logo), il peut s’avérer plus difficile pour les utilisateurs d’identifier rapidement la vignette de votre application.

    Les images suivantes illustrent les vignettes qui utilisent les éléments de type texte et image du modèle pour véhiculer la personnalisation de manière inappropriée. Notez que dans les deux cas, les vignettes utilisent également le nom ou le logo tel qu’il est conçu. Par conséquent, la personnalisation supplémentaire est redondante.

    Vignette illustrant la personnalisation dans un élément de type texte et vignette illustrant la personnalisation dans un élément de type image

    Pour plus d’informations sur le nom et le logo, voir Démarrage rapide : création d’une vignette par défaut à l’aide de l’éditeur de manifeste de Visual Studio.

  • Si le nom de votre application ne tient pas dans l’espace fourni par le « nom court » facultatif, utilisez une version abrégée ou un acronyme significatif. Par exemple, vous pouvez utiliser « Jeu Contoso » pour désigner le passionnant « Jeu Contoso version 3 ». Les noms qui dépassent le nombre maximal de pixels autorisé sont tronqués avec des points de suspension. La longueur maximale du nom est d’environ 40 caractères sur deux lignes, mais ce chiffre peut varier en fonction des lettres spécifiques utilisées. D’un point de vue de la conception, il est préférable d’utiliser des noms d’applications courts. Notez que vous pouvez également spécifier un nom plus long pour votre application (« nom d’affichage ») dans votre manifeste. Ce nom est utilisé dans l’affichage Applications et dans l’info-bulle, mais pas sur la vignette.
  • N’utilisez pas de vignettes pour les annonces publicitaires.
  • Évitez l’utilisation excessive de couleurs criardes dans les vignettes. Les vignettes simples, nettes et élégantes ont plus de succès que celles qui attirent l’attention de manière exagérée.
  • N’utilisez pas des images sur lesquelles figure du texte ; pour le contenu textuel, utilisez un modèle comportant des champs de texte. L’affichage du texte d’une image n’est pas aussi net que le rendu du texte d’une vignette. Si une image fournie n’est pas appropriée à l’affichage actuel, elle risque d’être mise à l’échelle, ce qui peut dégrader un peu plus sa lisibilité.
  • Ne comptez pas sur les vignettes pour envoyer aux utilisateurs des informations urgentes en temps réel. Par exemple, la vignette n’est pas le support approprié pour une application de communication destinée à informer l’utilisateur en cas d’appel entrant. Les notifications toast constituent un bien meilleur support pour transmettre les messages en temps réel.
  • Évitez d’utiliser un contenu d’image ressemblant à un lien hypertexte, à un bouton ou à un autre contrôle. Les vignettes ne prennent pas ces éléments en charge et la totalité de la vignette doit former un objectif de clic unique.
  • N’utilisez pas les dates et heures relatives (exemple : « il y a deux heures ») pour les notifications par vignettes, car celles-ci sont statiques alors que le temps s’écoule, ce qui rend le message inexact. Utilisez une date et une heure absolues, par exemple : « 11h00 ».
  • Dans la mesure où une vignette d’application ne peut lancer l’application que dans son écran d’accueil, les mises à jour de vignettes doivent indiquer les éléments de l’application facilement accessibles à partir de l’écran d’accueil. Par exemple, la vignette d’une application d’actualités doit afficher uniquement les articles que l’utilisateur peut trouver facilement sur l’écran d’accueil de l’application après avoir cliqué sur la vignette.

Utilisation de notifications par vignettes

Choix de la méthode de notification appropriée pour la mise à jour de votre vignette

Il existe plusieurs mécanismes qui permettent de mettre à jour une vignette dynamique :

  • Appels d’API locaux
  • Notifications planifiées à usage unique, à l’aide du contenu local
  • Notifications Push, envoyées à partir d’un serveur cloud
  • Notifications périodiques qui extraient les informations d’un serveur cloud à un intervalle fixe

Le choix du mécanisme à utiliser dépend en grande partie du contenu à afficher et de la fréquence de mise à jour du contenu. La majorité des applications utilisent probablement un appel d’API local pour la mise à jour de la vignette lorsqu’une application est lancée ou que son état change. Cela permet de s’assurer que la vignette est à jour au lancement et à la sortie. L’utilisation de notifications locales, Push, planifiées ou par interrogation (individuellement ou en alternance) dépend complètement de l’application. Par exemple, un jeu peut utiliser des appels d’API locaux pour mettre à jour la vignette chaque fois qu’un joueur atteint le meilleur score. Dans le même temps, le jeu peut utiliser des notifications Push pour envoyer au joueur les meilleurs scores de ses amis.

Pour plus d’informations sur le choix du mécanisme approprié pour mettre à jour votre vignette, voir Choix d’un mode de remise de notification.

À quelle fréquence votre vignette doit-elle être mise à jour ?

Si vous choisissez d’utiliser une vignette dynamique, réfléchissez à sa fréquence de mise à jour.

  • Dans le cas des contenus personnalisés, par exemple l’énumération d’un nombre de messages ou la désignation du joueur dont c’est le tour dans un jeu, nous vous recommandons de mettre à jour la vignette dès que l’information est disponible, en particulier si l’utilisateur risque de remarquer que le contenu de la vignette est obsolète, incorrect ou manquant.
  • Pour le contenu non personnalisé, par exemple les mises à jour météorologiques, nous vous recommandons de mettre à jour la vignette une seule fois toutes les 30 minutes au maximum. Cela permet à votre vignette d’être mise à jour sans gêner l’utilisateur.

Expiration des notifications par vignette et de badge

Le contenu de votre vignette ne doit pas être conservé plus longtemps que nécessaire. Définissez un délai d’expiration sur toutes les notifications par vignette et de badge qui soit pertinent pour votre application. Par défaut, les vignettes locales et planifiées ainsi que les badges n’expirent jamais. Le contenu par vignette et de badge envoyé par notifications Push ou périodiques expire trois jours après son envoi. Quand une notification expire, le contenu est supprimé de la vignette ou de la file d’attente, et n’est plus présenté à l’utilisateur.

Vous pouvez définir une date et une heure spécifiques pour l’expiration du contenu de la notification. Un délai d’expiration explicite est très utile pour les contenus dont la durée de vie est limitée. De même, si votre service cloud arrête d’envoyer des notifications, si votre application n’est pas exécutée pendant longtemps, ou si l’utilisateur se déconnecte du réseau durant un long moment, une expiration explicite garantit la suppression du contenu périmé malgré l’état de connectivité du système.

Par exemple, au cours d’une journée active d’échanges sur le marché boursier, vous pouvez doubler le délai d’expiration de la mise à jour du cours d’une action par rapport à l’intervalle d’envoi (une heure après l’envoi de la notification, si vous envoyez des notifications chaque demi-heure). Autre exemple, dans une application d’infos, le délai d’expiration approprié pour la mise à jour quotidienne des vignettes d’infos est d’une journée.

La définition de l’expiration dépend du mode de remise. Dans le cas des notifications Push et périodiques, elle est définie dans les en-têtes HTTP utilisés pour communiquer avec le service cloud qui remet les notifications. Vous pouvez définir l’expiration des notifications locales et planifiées dans le cadre de l’appel d’API.

Pour plus d’informations, voir En-têtes des demandes et des réponses des services de notifications Push BadgeNotification.ExpirationTime, ScheduledTileNotification.ExpirationTime et TileNotification.ExpirationTime.

Vignettes et badges sur l’écran de verrouillage

Pour déterminer si votre application peut être présente sur l’écran de verrouillage, vous devez comprendre le fonctionnement et les limites de l’écran de verrouillage. Vous trouverez ci-dessous un résumé de l’écran de verrouillage. Pour plus d’informations, voir Vue d’ensemble des écrans de verrouillage.

  • Sept badges d’application au maximum peuvent apparaître sur l’écran de verrouillage. Les informations de badge reflètent les informations de badge situées sur la vignette de l’écran d’accueil de l’application. Le badge (glyphe ou numéro) est accompagné d’une icône monochrome (logo) permettant d’identifier l’application à laquelle le badge est associé.
  • Une seule de ces sept applications peut occuper un emplacement d’état détaillé, ce qui lui permet d’afficher le contenu textuel de la dernière mise à jour de vignette de l’application.
  • La vignette d’état détaillé de l’écran de verrouillage ne montre pas les images incluses dans cette mise à jour de vignette.
  • Il revient à l’utilisateur de déterminer quelles sont les applications qui peuvent afficher des informations sur l’écran de verrouillage et, parmi ces dernières, quelles sont celles qui peuvent afficher un état détaillé.
  • Toutes les applications présentes sur l’écran de verrouillage peuvent également exécuter des tâches en arrière-plan. Toutes les applications qui peuvent exécuter des tâches en arrière-plan sont présentes sur l’écran de verrouillage. Une application ne peut pas utiliser de tâches en arrière-plan sans revendiquer également un emplacement sur l’écran de verrouillage.
  • La file d’attente de notifications n’est pas prise en charge par la vignette d’état détaillé de l’écran de verrouillage. Seule la dernière mise à jour est affichée.
  • Si une application est présente sur l’écran de verrouillage et si l’option Compatible toast a la valeur « Oui » dans son manifeste, elle affiche ses notifications toast sur l’écran de verrouillage lorsque ce dernier est affiché. Le toast affiché sur l’écran de verrouillage est identique au toast affiché ailleurs.
  • Les mises à jour de vignette, les mises à jour de badge et les notifications toast ne sont pas spécifiquement conçues pour l’écran de verrouillage ou envoyées vers ce dernier. En tant qu’expéditeur, vous ne savez pas si l’appareil est actuellement verrouillé. Pour une application avec présence de l’écran de verrouillage, toute notification est reflétée à la fois sur l’écran d’accueil et l’écran de verrouillage.

Caractéristiques d’une présence efficace sur l’écran de verrouillage

La seule manière pour une application d’avoir une présence sur l’écran de verrouillage est d’obtenir l’autorisation explicite de l’utilisateur. Cette autorisation peut être obtenue suite à une demande de la part de votre application (une seule demande est permise) ou manuellement par le biais de la page Paramètres. En accordant cette autorisation, l’utilisateur déclare que les informations provenant de votre application sont importantes à ses yeux, et que votre application doit donc les protéger. Par conséquent, votre première préoccupation doit être de déterminer si votre application remplit les conditions pour être présente sur l’écran de verrouillage.

Pour qu’une application soit présente sur l’écran de verrouillage, elle doit avoir les caractéristiques suivantes :

Les informations sont gérées rapidement.

Si l’écran de verrouillage est affiché, l’utilisateur n’interagit pas avec l’appareil actuellement. Par conséquent, les informations de mise à jour que votre application affiche sur l’écran de verrouillage doivent être visibles et compréhensibles en un coup d’œil. Par analogie, pensez à un appel entrant sur un téléphone cellulaire. Vous jetez un coup d’œil au téléphone pour voir qui vous appelle, puis vous décidez de répondre ou de laisser la messagerie vocale se déclencher. Les informations affichées sur l’écran de verrouillage doivent être aussi faciles à comprendre et à gérer que ce qui s’affiche à l’écran du téléphone cellulaire. Toutes les autres caractéristiques prennent celle-ci en charge.

Les informations sont toujours actualisées.

Les mises à jour de badge, les mises à jour de vignette et les notifications toast, qu’elles soient affichées sur l’écran d’accueil ou sur l’écran de verrouillage, sont toutes potentiellement interactives. En fonction des informations fournies par ces notifications, l’utilisateur peut décider de lancer ou non l’application correspondante, par exemple pour lire un nouveau message électronique ou pour commenter une publication de média social. À partir de l’écran de verrouillage, cela signifie également déverrouiller l’appareil. Par conséquent, les informations doivent être mises à jour pour permettre à l’utilisateur de faire un choix avisé. Si les utilisateurs s’aperçoivent que les informations de votre application sur l’écran de verrouillage ne sont pas à jour, vous perdez leur confiance. En outre, ils vont probablement se tourner vers une application d’infos plus fiable pour occuper l’emplacement d’écran de verrouillage de votre application.

Bons exemples : informations à jour

  • Une application de messagerie envoie une notification quand un nouveau message arrive. Si cette notification est ignorée, l’application met à jour le nombre de messages manqués sur son badge. Si l’utilisateur est présent, il peut activer l’écran pour évaluer l’importance du message, puis choisir d’y répondre rapidement ou de le laisser en attente. Si l’utilisateur est absent, il voit un décompte précis des messages manqués à son retour.

  • Une application de messagerie utilise son badge pour afficher le nombre de messages non lus. Elle met à jour le badge immédiatement lorsque du courrier arrive. Un utilisateur peut rapidement activer son écran pour vérifier le nombre de messages non lus et s’assurer que le décompte est exact. Il dispose des informations nécessaires pour décider s’il souhaite déverrouiller son appareil et lire le courrier.

Mauvais exemples : informations obsolètes

  • Une application de messagerie met à jour le nombre de messages manqués sur son badge, une seule fois par demi-heure. L’utilisateur ne peut pas se fier au décompte indiqué par le badge pour décider de déverrouiller ou non l’appareil.
  • Une application météo qui utilise l’emplacement d’état détaillé continue d’afficher une alerte météo majeure après l’expiration de l’alerte. Non seulement l’utilisateur dispose d’informations incorrectes, mais en outre l’erreur est particulièrement flagrante si le texte indique le moment où l’alerte prend fin, car l’utilisateur constate alors qu’il s’agit d’informations obsolètes. L’utilisateur n’a plus confiance en la capacité de l’application à le maintenir correctement informé. L’application doit effacer ces informations, une fois qu’elles ont expiré.
  • Une application de calendrier continue d’afficher un rendez-vous passé. À nouveau, l’application doit effacer ces informations, une fois qu’elles ont expiré.

Les informations sont compréhensibles sans contexte supplémentaire.

Ces informations contextuelles ne sont pas présentes sur l’écran de verrouillage :

  • Vignette associée au badge, lorsque l’application n’est pas autorisée à afficher l’état détaillé. Même lorsque l’état détaillé est affiché, le badge est physiquement distinct de la vignette. L’image du logo en regard d’un badge est la seule identification de l’application représentée.
  • Images dans les mises à jour de vignette. Seule la partie texte de la mise à jour est affichée dans l’emplacement d’état détaillé.
  • File d’attente de notifications. Seule la mise à jour la plus récente est affichée dans l’emplacement d’état détaillé.

Par conséquent, vos mises à jour doivent être compréhensibles par l’utilisateur sans le contexte supplémentaire disponible sur l’écran d’accueil. Là encore, n’oubliez pas que les notifications ne peuvent pas être ciblées spécifiquement sur l’écran de verrouillage. Par conséquent, toutes les communications de mise à jour de votre application doivent satisfaire à la règle « compréhensible sans contexte supplémentaire ».

Remarque  Contrairement à la vignette détaillée, le toast inclut à la fois une image (si elle est présente) et du texte — un toast affiché sur l’écran de verrouillage est identique à un toast affiché ailleurs ; il ne perd donc pas le contexte.

Bons exemples : compréhensible sans contexte supplémentaire

  • Une application de messagerie utilise son badge pour afficher le nombre de messages non lus. Il est possible que sa vignette sur l’écran d’accueil affiche plus d’informations, par exemple des extraits de texte des messages les plus récents ou des photos des expéditeurs. Toutefois, le contenu affiché par le badge est compréhensible sans complément d’informations.
  • Une application de réseau social utilise l’emplacement d’état détaillé pour informer l’utilisateur sur les activités récentes de ses amis. Quand un ami lui envoie un message, le nom de cet ami est inclus dans le texte de la notification (par exemple « Gabriel vous a envoyé un nouveau message. »). Sur l’écran d’accueil, l’utilisateur peut voir l’image de son ami dans la notification, alors que sur l’écran de verrouillage, même en l’absence d’image, le texte identifie clairement l’expéditeur du message.

Mauvais exemples : incompréhensible sans contexte supplémentaire

  • Une application de messagerie met à jour le dernier message reçu sur sa vignette et n’affiche que l’image de l’expéditeur et le texte du message. Sur l’écran d’accueil, l’utilisateur identifie clairement l’auteur du message. Dans l’écran de verrouillage, sans image de l’expéditeur, l’utilisateur n’a aucune idée de l’auteur du message.
  • Une application de réseau social met à jour sa vignette avec un photomontage, sans texte. Dans l’écran d’accueil, cela rend la vignette esthétique et dynamique. Sur l’écran de verrouillage, comme il n’y a aucun texte dans la mise à jour de vignette, rien ne s’affiche.

Les informations doivent être personnelles et utiles pour l’utilisateur.

Deux des principaux objectifs de l’écran de verrouillage consistent à fournir une zone personnalisée pour l’utilisateur et à afficher les mises à jour des applications. Évaluez ces deux critères pour juger si votre application est un bon candidat pour une présence sur l’écran de verrouillage.

Les applications présentes sur l’écran de verrouillage sont très particulières — il ne peut y en avoir que sept à la fois sur l’écran de verrouillage. En donnant à une application l’un de ces précieux emplacements sur l’écran de verrouillage, l’utilisateur indique que les informations en provenance de l’application sont suffisamment importantes pour être vues, même lorsque l’utilisateur ne se sert pas activement de son appareil. Par conséquent, l’application doit fournir des informations à la fois personnelles et utiles pour l’utilisateur.

Remarque  Par définition, l’écran de verrouillage est affiché quand l’appareil est verrouillé. Aucune ouverture de session ou autre opération de sécurité n’est requise pour afficher le contenu de l’écran de verrouillage. Par conséquent, bien que les informations affichées sur cet écran soient, dans l’idéal, personnalisées, n’oubliez pas que tout le monde peut les voir.

Bons exemples : informations personnalisées pour l’utilisateur

  • Une application de messagerie affiche le nombre de messages électroniques non lus dans le compte de l’utilisateur.
  • Une application de messagerie affiche le nombre de messages manqués envoyés à l’utilisateur.
  • Une application d’infos affiche le nombre de nouveaux articles dans les rubriques favorites signalées par l’utilisateur.

Mauvais exemples : informations impersonnelles

  • Une application d’infos affiche le nombre total de nouveaux articles en provenance de son service, sans tenir compte des préférences exprimées par l’utilisateur.
  • Une application de shopping envoie une notification au sujet d’une vente, mais sans tenir compte des préférences exprimées par l’utilisateur sur les articles ou les catégories qui l’intéressent.

Il est préférable de ne rien afficher plutôt que d’afficher toujours le même état

Les informations ne doivent s’afficher qu’en cas de modification

Comme nous l’avons dit auparavant, l’objectif est de rendre les informations visibles d’un coup d’œil sur l’écran de verrouillage. À cette fin, si une application n’affiche pas de badge, un espace est laissé sur l’écran de verrouillage, à l’emplacement où le badge est censé apparaître. Cela permet à l’utilisateur de remarquer plus facilement un élément attirant leur attention — l’affichage d’un badge et d’un logo à la suite d’un événement est plus facile à remarquer, car cela suggère quelque chose de nouveau.

N’affichez pas l’état juste pour le plaisir de le faire. Un état dont la durée est longue ou qui ne change jamais encombre l’écran de verrouillage en masquant les informations plus importantes. Un badge ne doit s’afficher qu’à la suite d’un événement dont l’utilisateur doit prendre connaissance. Il en est de même pour une mise à jour de vignette. Une fois que vous avez supprimé le contenu de notification obsolète de votre vignette, celle-ci retrouve son image par défaut sur l’écran d’accueil. En outre, rien ne s’affiche sur l’écran de verrouillage.

Bons exemples : affichage des informations pertinentes uniquement

  • Une application de courrier affiche un badge uniquement lorsqu’il y a du courrier non lu. Lorsqu’un nouveau message arrive, son badge est mis à jour et affiché.
  • Une application de messagerie affiche l’état de sa connexion uniquement lorsque l’utilisateur ne peut pas recevoir de messages. L’état « connecté » est censé être l’état par défaut de l’application. Par conséquent, il est inutile de fournir cette information. « Tout va bien » n’est pas une notification interactive. Toutefois, le fait d’informer l’utilisateur qu’il ne peut pas recevoir de messages est plus pertinent.

Mauvais exemples : état de longue durée

  • Une application de messagerie n’affiche pas le nombre de messages non lus et indique un état de connexion jusqu’à l’arrivée d’un nouveau message. Cela réduit la capacité de l’utilisateur à voir rapidement s’il a reçu un nouveau message, car le badge est toujours présent.
  • Une application de calendrier affiche un message indiquant que l’utilisateur n’a aucun rendez-vous. Une fois de plus, cela réduit la visibilité immédiate des informations de l’emplacement d’état détaillé, car il y a toujours un élément affiché à cet emplacement.

Seule l’arrivée d’une notification toast doit être accompagnée d’un son.

N’incluez dans votre application aucun code qui lit du son lors de la mise à jour de votre badge ou vignette. Toutefois, un toast en arrivée peut lire un son si sa conception l’exige.

En suivant les recommandations décrites dans cet article, vous pouvez créer des applications qui affichent des informations pertinentes de manière appropriée sur l’écran de verrouillage. Cela augmente la satisfaction et la confiance des utilisateurs à l’égard de votre application.

Quand utiliser l’API de demande d’écran de verrouillage ?

Appelez l’API de demande d’écran de verrouillage (RequestAccessAsync) uniquement si votre application a réellement besoin de privilèges en arrière-plan pour fonctionner correctement. Étant donné que seuls sept emplacements en arrière-plan sont disponibles, les utilisateurs doivent faire la distinction entre les applications qui ont réellement besoin de privilèges en arrière-plan pour fonctionner correctement et celles qui fonctionnent correctement sans (même si elles peuvent bénéficier de fonctionnalités supplémentaires avec ces privilèges).

Si une application a absolument besoin de privilèges en arrière-plan pour répondre aux attentes de l’utilisateur, nous vous recommandons d’utiliser l’API de demande pour inviter l’utilisateur à placer l’application sur l’écran de verrouillage.

En revanche, si une application peut répondre aux attentes de l’utilisateur sans disposer de privilèges en arrière-plan, nous vous conseillons de ne pas inviter de manière explicite l’utilisateur à placer l’application sur l’écran de verrouillage. Au lieu de cela, laissez l’utilisateur placer son application sur l’écran de verrouillage par le biais de la page Personnaliser des Paramètres du PC.

Exemples d’applications qui doivent appeler l’API de demande :

  • application de messagerie qui requiert des privilèges en arrière-plan pour recevoir des messages lorsqu’elle n’est pas au premier plan ;
  • application de courrier électronique qui requiert des privilèges en arrière-plan pour synchroniser la boîte de réception de l’utilisateur lorsqu’elle n’est pas au premier plan.

Exemples d’applications qui ne doivent pas appeler l’API de demande :

  • application météo qui utilise des notifications périodiques plutôt qu’une activité en arrière-plan pour mettre à jour ses bulletins ;
  • application d’actualités qui met à jour le nombre de nouveaux articles sur son badge à une heure précise durant la journée.

Remarque  Votre application ne doit pas implémenter sa propre boîte de dialogue pour demander aux utilisateurs d’ajouter l’application à l’écran de verrouillage. Si votre application nécessite un accès à l’écran de verrouillage pour s’exécuter correctement, reposez-vous sur la boîte de dialogue présentée par l’API de demande d’écran de verrouillage. Si un utilisateur a précédemment refusé les droits de l’écran de verrouillage à votre application par le biais de cette boîte de dialogue, cette dernière risque de ne plus s’afficher. Dans ce cas, vous pouvez utiliser du texte inséré dans votre application pour diriger les utilisateurs sur la page Personnaliser des Paramètres du PC afin d’ajouter manuellement votre application à l’écran de verrouillage.

Liste de vérification des conditions requises par le Windows Store

Pour connaître les conditions requises par le Windows Store, voir Critères de certification pour les applications Windows. Sachez que pour être accepté dans le Windows Store, vous ne pouvez utiliser ni vos vignettes ni vos notifications pour afficher des annonces publicitaires.

Rubriques associées

Pour les concepteurs
Catalogue de modèles de vignette
Vue d’ensemble des vignettes et des notifications par vignette
Vue d’ensemble des badges
Vue d’ensemble des écrans de verrouillage
File d’attente des notifications
Choix d’un mode de remise de notification
Recommandations en matière de vignettes secondaires.
Pour les développeurs (applications Windows Runtime en JavaScript et HTML)
Démarrage rapide : envoi d’une mise à jour de vignette
Démarrage rapide : envoi d’une mise à jour de badge
Démarrage rapide : affichage des notifications sur l’écran de verrouillage
Démarrage rapide : création d’une vignette par défaut à l’aide de l’éditeur de manifeste de Visual Studio
Comment planifier une notification par vignette
Comment configurer des notifications périodiques pour des vignettes
Comment utiliser la file d’attente de notifications avec des notifications locales
Schéma XML des vignettes
Pour les développeurs (applications Windows Runtime en C#/VB/C++ et XAML)
Démarrage rapide : envoi d’une mise à jour de vignette
Démarrage rapide : envoi d’une mise à jour de badge
Démarrage rapide : affichage des mises à jour des vignettes et des badges sur l’écran de verrouillage
Comment utiliser la file d’attente de notifications avec des notifications locales
Démarrage rapide : création d’une vignette par défaut à l’aide de l’éditeur de manifeste de Visual Studio
BackgroundExecutionManager.RequestAccessAsync
Exemples
Exemple de vignettes et de badges d’application
Exemple d’application de l’écran de verrouillage

 

 

Afficher:
© 2014 Microsoft. Tous droits réservés.