La vraie nature de WinRT

La semaine dernière, Microsoft organisait un évènement dénommé Build Windows, dans le but de faire la lumière sur la dernière version de Windows, nom de code Windows 8, prévu pour débarquer l’année prochaine. Lors de cet évènement, MS en a profité pour dévoiler un nouveau type d’application pour Windows : les applications Metro, orientées grand public et basées sur une nouvelle couche logicielle dénommée Windows Runtime alias WinRT.

Depuis, on peut entendre beaucoup de bruit sur la véritable nature de WinRT : est-ce que WinRT remplace Silverlight ? WPF ? Win32 ? A tel point que cela en devienne assez dur de comprendre le concept, pourtant très simple et très puissant à la fois. Heureusement plusieurs bons articles sont apparus sur la toile pour expliquer qu’est-ce que WinRT et comment il va fonctionner conjointement avec le reste du système d’exploitation. Cet article va donc essayer d’expliquer ce qu’est véritablement WinRT et pourquoi le concept est si puissant !

Windows 8, le premier Windows schizophrène

Comme le faisait remarquer Mary Jo Foley sur son blog All About Microsoft, c’est que s’il y a bien une slide que tout le monde gardera en mémoire du Build, c’est celle-ci, qui représente l’architecture des applications pour Windows 8.

Ce qui est intéressant ici est la séparation entre les Metro Style apps, les fameuses applications développées exclusivement pour Windows 8, et … tout le reste ! Oui la partie droite en bleu représente l’intégralité des applications existantes ! Cela aurait d’ailleurs dû couper court à toutes les discutions de mort de Silverlight / .NET : tout cela sera présent dans Windows 8 comme c’est le cas dans Windows 7 !

Comment dans ce cas, vont cohabiter les différentes applications ? Quel est l’intérêt de créer un nouvel écosystème applicatif, quand on a déjà, et de loin, le plus vaste ?

Et bien tout simplement, parce que Windows 8 a deux personnalités ! Une personnalité qu’il a héritée de son père Windows 7, qui reprend toute la partie bureautique de Windows (bureau, barre de lancement rapide, icônes, fichier, et ainsi de suite), et une personnalité qu’il a hérité de son lointain cousin Windows Phone 7 (je ne veux pas savoir comment c’est arrivé !), qui instaure pour la première fois dans Windows une interface très très très orientée grand public, avec les fameuses live tiles, notifications, et les applications sans chrome qui mette l’accent sur le contenu, la typographie, l’expérience utilisateur… Attendez mais ça me rappelle quelque chose !

Effectivement, cela défini parfaitement Metro, cet ensemble de règles qui font qui ont permis de créer une toute nouvelle expérience utilisateur sur Windows Phone, comme je l’avais décrit l’année dernière dans cet article : https://sebastienmornas.wordpress.com/2010/08/29/qu-est-ce-que-metro/ Et c’est effectivement un bien bel exemple d’interface Metro que nous a présenté avec le nouveau « Start screen » de Windows 8, qui remplacera donc le menu démarrer qui était apparu avec Windows 95 ! Ils nous avaient prévenus, Windows 8 est un tournant dans l’histoire de Windows !

Nous y voilà, Windows 8 aura donc deux facettes, une classique qui sera un Windows 7 amélioré, et une qui transforme le PC en grand Windows Phone. Qui a dit « tablette » ? Bien évidemment le but avoué de Windows 8 est de conquérir le marché des tablettes tout en conservant celui des ordinateurs. Cette interface Metro est ainsi une aide précieuse pour faire adopter Windows aux tablettes, car bien qu’elle soit prévue pour être utilisée autant à la souris / clavier qu’aux doigts, on imagine sans mal que le tactile sera notre moyen favoris pour naviguer dedans !

WinRT, un composant phare de Windows 8 Metro

Une des nouveautés de Windows 8 est également sa compatibilité avec l’architecture ARM, qui n’était pas supporté jusqu’à Win8. Cela rentre aussi dans la stratégie de pousser Windows sur tablette, un secteur où les processeurs x86 sont présents, mais pas dominants. Seulement voilà, comment porter toutes les applications natives de Windows sur ARM, sachant que le jeu d’instruction est sensiblement différent ? En un mot : impossible (ou plutôt « trop contraignant » mais ça faisait deux mots).

C’est pour cela que Microsoft a besoin de constituer un nouvel écosystème d’applications résolument orienté vers le grand public, en plus de son écosystème d’applications existantes ; le but étant également que toutes ces nouvelles applications soient autant utilisable à la souris que via un écran tactile. Oui je parle bien des applications Metro, qui pourront fonctionner de la même manière sur toutes les versions de Windows 8 de la même manière, même sur un système ARM. Pour cela, pas besoin de compiler son application pour plusieurs architectures, c’est une toute nouvelle couche logicielle qui permettra aux applications Metro de communiquer avec l’OS : le Windows Runtime.

Je pense que ce n’est que maintenant, après avoir compris le contexte derrière Windows 8 que l’on peut réellement saisir ce qui se cache derrière le diagramme présenté au début de l’article. Dans le schéma présenté au début de l’article, WinRT est une couche qui descend aussi bas que Internet Explorer, Win32 et .NET / Silverlight ; pourquoi ?

Parce que WinRT n’est pas une couche de plus qui s’insère entre deux couches existantes, bien au contraire, c’est une couche entièrement indépendante de Win32, qui discute directement avec l’OS sans intermédiaire ! C’est en ce sens que Paul Thurrott écrit son article WinRT is replacing Win32, bien que pour moi cela soit faux : WinRT est une alternative, pas un remplacement !

Mais WinRT ne s’arrête pas au niveau de Win32, mais qui monte également plus haut, incorporant une partie des blocs HTML / JavaScript, C / C++ et C# / VB.NET, et il y a une raison à cela : WinRT permet d’écrire des applications via des langages natifs (C/C++), managés (C#/VB.NET) et même web (HTML/JavaScript), et contient donc des mécanismes pour pouvoir utiliser les mêmes APIs depuis tous les langages supportés (nous y reviendront plus tard).

WinRT, en soit, est composé d’un grand nombre d’APIs, qui ressemble grandement à des APIs .NET, et qui sont accessibles aux trois langages. Magique ? Non. Ingénieux ? Certainement ! Derrière ce sont des APIs bas niveaux, entièrement développée en C++, pour s’assurer une performance maximale, mais qui sont exposées en utilisant un format de métadonnées standardisée par Microsoft (ECMA 335 pour les puristes, et oui, c’est les mêmes métadonnées utilisées par le .NET Framework !), ce qui permet d’utiliser de la réflexion, des langages dynamiques, etc.

En ce qui concerne la partie graphique, WinRT contient également toutes les mécaniques pour écrire des interfaces en XAML, comme on le ferait pour écrire des interfaces Silverlight ou WPF. C’est en cela que Silverlight et WinRT + XAML se ressemble beaucoup. Mais derrière, c’est très différent. La partie graphique de WinRT est entièrement exécuté par DirectX, de manière native, ce qui assure des performances à hauteur et un support encore plus abouti du GPU. Comme DirectX est extrêmement présent dans WinRT, cela promet également de pouvoir écrire des jeux DirectX encore moins couplé au matériel.

Les wrappers JavaScript et C# / VB.NET

Si les APIs de WinRT sont écrite en C++, on peut comprendre qu’utiliser WinRT depuis C++ est assez naturel. En revanche, comment peut-on l’utiliser depuis JavaScript ou les langages basés sur .NET ?

Pour ce qui est du C# et du VB.NET, le principe est le même que le P/Invoke couramment utilisé par les développeurs .NET pour appeler des méthodes définie dans les DLL du système. Le principe, mais pas la syntaxe, car pour consommer un objet WinRT, il suffit de l’instancier comme n’importe quel objet .NET et de l’utiliser de la manière la plus managée qui soit. Fantastique ! Mais en ce qui concerne le reste du Framework ? Pas d’inquiétude, le CLR 4.5 sera là pour exécuter notre code managé, mais sera simplement restreint pour ne pas utiliser les APIs bas-niveau du Framework (par exemple la gestion de fichiers). Miguel De Icaza, le papa du projet Mono, a justement écrit un excellent article sur WinRT à ce propos.

Pour ce qui est de JavaScript et HTML, il faudra passer par une bibliothèque JavaScript nommée WinJS, qui ne fonctionnera que dans Windows 8 (pas sur le web, ce qui est normal) et qui offrira les mêmes APIs que pour .NET / C++ dans un style résolument plus JavaScript. Le code JavaScript, ainsi que l’interface HTML5 / CSS3 sera interprété par le même moteur de rendu / exécution de script que IE10, bien que l’application ne soit pas vraiment exécutée par ledit navigateur.

Pour conclure

Windows Runtime, je ne sais pas de qui c’était l’idée, mais c’est une fort bonne idée ! Avec WinRT, il est possible de faire des applications avec le style d’écriture .NET (et la productivité qui va avec), tout en manipulant des objets natifs sans le savoir, ce qui augmente sensiblement les performances. Plus important encore, WinRT permet de fédérer l’écriture d’applications pour la plateforme Windows, le but étant de recréer un écosystème d’application modernes, fluide et intuitives. J’ai hâte d’y être !

Publicités

Les 7 fautes à éviter lors du design d’une app WP7

Alfred Astort de l’équipe de l’équipe de « User Experience Design Lead » sur Windows Phone 7, a commencé une série de posts extrêmement intéressants sur le design d’applis sur le blog officiel de Windows Phone, où il reprend les erreurs les plus courantes à éviter lors du design d’une application WP7. Il en est actuellement à son septième article, et vous pourrez lire tous ces posts depuis cette page : http://windowsteamblog.com/windows_phone/b/wpdev/archive/2010/11/05/top-ten-things-to-keep-an-eye-on.aspx

Parce que je pense que les points qu’il aborde sont absolument inévitables pour tout développeur qui vise le Marketplace, je vous propose un article récapitulatif qui reprend les 7 premiers points. Les 3 suivants pourront également bénéficier d’un article étant donné qu’ils sont également particulièrement importants.

1. Icône de l’application

L’icône de l’application, visible sur le Marketplace ou sur l’écran de démarrage du téléphone, est la première chose de votre application que vos futurs-utilisateurs vont voir. C’est ce qui va faire qu’un utilisateur ne va peut-être ne même pas cliquer sur votre application. Vous pouvez avoir créé une magnifique application qui accompli sa tâche à merveille, si l’utilisateur ne vous donne pas votre chance, c’est beaucoup de travail
pour rien… C’est pour ça que l’icône d’application doit être au moins aussi soigné que tout le reste de l’application !

Sérieusement ? (Ou devrais-je dire Really ?) Ces applications ne donnent pas envie… du TOUT !

Premier conseil avisé de la part d’Alfred : faîtes vous aider d’un designer si vous le pouvez ! Honnêtement il n’y a pas photo, les designers ont quelque chose que nous, développeurs, n’avons pas. Maintenant il est vrai que nous n’avons pas tous la chance d’avoir un designer sous la main pour travailler le logo de notre application. Heureusement, en évitant certaines erreurs, même les moins graphistes pourront faire des icônes qui rendront l’utilisateur heureux :

  1. Eviter les typographies 3D : non, l’effet WordArt 3D n’est pas votre ami ! Pour rappel Metro c’est de la 2D dans un environnement en 3D (projections). La police 3D c’est du passé, point.
  2. Eviter les dégradés de couleurs : comme j’abordais le sujet dans mon article sur le dithering, les guidelines Microsoft déconseillent l’utilisation de dégradés, principalement parce que les écrans de certains Windows Phone les gèrent très mal et font des barres hideuses.
  3. Eviter les coins arrondis : Windows Phone n’est PAS iOS. Microsoft a décidé de faire quelque chose de différent de son concurrent fruité, et Metro c’est des formes droites et épurés. A éviter donc, même si Microsoft ne montre pas le bon exemple avec l’application Facebook officielle !
  4. Eviter les fonds noirs ou blancs : pour que l’on voie votre icône quel que soit le thème choisi par l’utilisateur, privilégiez n’importe quelle couleur sauf le noir et le blanc (qui ne sont d’ailleurs pas vraiment des couleurs)
  5. Eviter les formes ambigües : certains ont bien compris que l’icône doit être simple, pour continuer dans la lignée des applications natives de WP7. Pour cela je ne peux qu’être d’accord avec eux. Cependant il ne faut pas tomber dans l’extrême inverse et faire un icône qui n’a aucun sens, et dont on ne comprend pas l’utilité de l’application décrite.
  6. Faire une icône colorée sur fond transparent : il est possible de mettre de la transparence dans les icônes d’application, ce qui permet de remplacer la transparence par la couleur d’accent choisie par l’utilisateur. Cependant si vous faites ça et que votre icône est coloré vous risquez que ladite icône disparaisse dans le fond. Au lieu de ça, si vous choisissez une icône à fond transparent, la seule couleur que vous devez utiliser est le blanc. Cela vous donnera le même rendu que les applications natives.

2. Le clavier ne doit pas cacher les boutons

Ce conseil s’applique principalement aux fenêtres de login : les boutons qui permettent de passer à l’écran suivant doivent être visible même quand le clavier est ouvert. Dans le cas contraire l’utilisateur ne va peut-être pas arriver à faire disparaitre le clavier, ou bien il va appuyer sur un autre bouton sans le vouloir, il ne vas plus comprendre ce qu’il se passe et ne sera pas heureux ! Ok, c’est un peu tiré par les cheveux, mais admettons… En tout cas le conseil sous-jacent d’Alfred est d’utiliser la barre d’application afin de garder toujours les actions importantes à portée de doigt.

3. Prendre en compte le thème de l’utilisateur

J’en ai déjà parlé dans un précédent billet, donc je ne m’attarderai pas sur ce point. Quand vous testez votre application, prenez bien soin de la tester en thème light et en thème dark. Faîtes attention aux problèmes de lisibilité, et utiliser les ressources du système pour que l’application soit toujours agréable, quel que soit le thème et la couleur d’accent choisie. L’autre solution est d’utiliser une copie du fichier de thème qui est propre à votre application, et donc de surcharger les couleurs dans un cas comme dans l’autre ; ce qui est une solution tout à fait acceptable. Dans ce cas vous n’avez que vos couleurs à gérer, mais gérez les biens !

4. Faites des applications manipulable au doigt

Contrairement à votre émulateur, les utilisateurs utiliseront leurs doigts pour naviguez dans votre application. Il faut donc adapter les zones de touché au doigt. Pour ça il est conseillé d’agrandir la zone de touché bien au-delà de la zone visuelle. Rapprocher trop les éléments les uns des autres introduit un risque pour l’utilisateur d’appuyer sur le mauvais bouton.

La bonne nouvelle c’est que les contrôles de Silverlight sont déjà optimisés par natures, en ayant naturellement un margin important. Si vous utilisez des contrôles personnalisés ou que vous modifiez les margins des contrôles existants, alors respectez scrupuleusement les guidelines de Metro sur les tailles minimums de cible, issus des recherches en expérience utilisateur menées par Microsoft.

Dans le document UI Design and Interaction Guide, à la page 75 on peut par exemple lire qu’une cible doit être au moins un carré de 34px avec un espacement d’au moins 8px. L’agrandissement de la zone de touché doit être d’au moins 60% de la taille de l’élément. Pour les éléments textuels touchables, la taille de police doit être d’au moins 15pts.

En conclusion, vérifiez toujours que votre application est toujours utilisable au doigt et vérifiez ça sur un téléphone !

5. L’utilisateur veut savoir ce qui se passe…

… Alors donnez-lui des indices ! Sur tous les éléments tactiles, vous pouvez utiliser l’effet « Tilt » (qui est décrit sur la MSDN : http://msdn.microsoft.com/en-us/library/ff941102(VS.92).aspx) pour montrer à l’utilisateur que le touché à bien un effet.

Pour les téléchargements ou les opérations qui prennent du temps, utiliser la ProgressBar pour montrer à l’utilisateur que l’application n’est pas plantée et qu’il doit patienter encore quelques instants. Si vous pouvez donner une estimation du temps restant les guidelines conseillent une progress bar à temps déterminé (IsIndeterminate = false) et l’inverse si on ne peut pas donner d’estimation.

Note : n’oubliez pas de mettre IsIndeterminate à false après que vous l’ayez fait disparaitre, sinon il se peut qu’elle impacte quand même vos performances…

6. Attentions aux contenus Web

Si vous intégrez du contenu Web dans votre application par le biais du composant WebBrowser, il y a quelques petites choses à ne pas oublier.

  • Empêchez de faire des zooms dans le contenu Web en réglant le viewport (height, width et user-scalable=no) pour que l’utilisateur ne se rende pas compte que le contenu est effectivement un contenu Web
  • Privilégiez de grandes tailles de police, à minima 15pt.
  • Veillez à ce que les champs (texte, listes, etc.) tiennent sur toutes la largeur de la page
  • De manière générale, évitez tous scrolling horizontal, qui pourrait faire penser à un panorama sans l’être
  • Faites en sorte que la charte graphique utilisée par la partie Web soit conforme au reste de l’application

En conclusion si vous utilisez du contenu Web, le reprendre tel quel ne serait pas acceptable du point de vue de l’expérience utilisateur. Pour plus de détails sur le moteur de rendu intégré dans le composant WebBrowser, reportez-vous à la page MSDN consacrée : http://msdn.microsoft.com/en-us/library/ff462082(VS.92).aspx

7. Placement des boutons dans l’application et les boutons à éviter

Il y a dans le dernier article deux points très importants sur les boutons (software et hardware). Premièrement il y a, comme vous le savez, trois boutons en façade sur tous les modèles de Windows Phone : un bouton retour, un bouton accueil et un bouton rechercher.

Ce que nous dit Alfred pour commencer est d’éviter dans l’application de mettre de bouton « Retour » ou de bouton « Accueil », le premier parce qu’il fait double emploi avec la touche physique et qu’il faut éviter de faire douter l’utilisateur, et le second parce qu’il risquerait de perturber l’utilisateur. « Si j’appuie sur Accueil est ce que cela m’amène sur l’écran du démarrage du téléphone comme le bouton physique ? Si j’appuie sur le bouton physique est ce que cela va m’amener sur l’écran d’accueil de l’application ? »

Tout en étant 100% d’accord avec cela, on pourrait quand même se demander pourquoi Microsoft ne permet pas la surcharge du bouton physique de recherche, ce qui permettrait d’éviter d’ajouter un bouton recherche qui fait double emploi dans nos applications, mais cela n’engage que moi.

Deuxième point, au sein de l’application, les boutons doivent être disposés de façon structurée. Bien évidemment, si vous pouvez utiliser la barre d’application (Pivot ou page simple), faite le ! Sinon, disposez vos boutons dans une structure simple et compréhensible (StackPanel, WrapPanel, etc.) pour ne pas laisser l’utilisateur pantois quand il découvrira votre interface.

En conclusion, on peut voir que de jour en jour le Marketplace se remplit à une vitesse toujours plus grande avec plus de 6000 applications. Pour moi ce chiffre ne veut pas dire grand-chose… Certes à cette vitesse le marketplace de BlackBerry sera dépassé dans quelques mois, mais la qualité doit tout de même primer sur la quantité. Je ne souhaite pas voir 100 000 applications comme c’est le cas sur Android, si ces applications ne sont pas faites avec le désir de contenter l’utilisateur avant tout.

Encore une fois, ça n’engage que moi…

Metro et les animations

Les animations font partie intégrante de Metro, l’UX de Windows Phone 7. Un certain nombre d’animations sont utilisées au sein même du système mobile de Microsoft ; reproduire ces animations peut donc permettre à une application de ressembler plus au reste du système et donc de ne pas perdre l’utilisateur avec une signalétique différente. Dans cet article nous verrons les différentes animations de WP7 et comment les implémenter dans son application. Les spécifications des animations proviennent du blog de Clarity Consulting : http://blogs.claritycon.com/blogs/kevin_marshall/archive/2010/10/12/wp7-page-transitions-sample.aspx

Les types d’animations

Voyons tout d’abord les différents types d’animations de Windows Phone 7. Chacun des types d’animation est utilisé dans des cas distincts, qui seront décrits à chaque fois. Une chose importante à noter est l’utilisation dans les animations d’Easing, c’est-à-dire que les animations ne sont pas linéaires et s’accélèrent ou se décélèrent dans le temps. Toutes les animations de Windows Phone 7 utilisent l’Easing Exponential 6 (entrée ou sortie).
Note : Comme décrit dans l’article de Clarity Consulting, si vos pages sont un peu complexes, l’exponentielle 6 sera peut-être trop rapide ; utilisez dans ce cas une exponentielle 3.
Pour chaque animation il y a plusieurs cas d’utilisation, en général un pour amener du contenu et l’autre pour enlever le contenu. Ces différents cas seront également décrits ci-dessous. Clarity Consulting a de plus réalisé une vidéo qui vous permettra de voir tout de suite ce qui se cache derrière les énigmatiques noms d’animations :

Turnstile et Turnstile Feather

Description

L’animation Turnstile est l’animation la plus courante dans l’interface Windows Phone 7 : cette animation qui rappelle le mouvement les pages d’un livre qui se tournent, est utilisée quand on lance une application, ou quand on arrive dans les paramètres pour prendre deux exemples parmi tant d’autres.
Il y a d’ailleurs une grosse différence entre ces deux cas précis : quand on lance une application, le splash screen arrive en block alors que les liens des configurations arrivent en tournant de manière similaire mais dont le mouvement est légèrement décalé. On appelle la première animation « Turnstile » et la seconde animation « Turnstile Feather ». La seule différence entre ces deux types d’animation est donc que le premier s’applique à un seul contrôle, alors que le second s’applique à une liste. Le décalage entre chaque élément du Turnstile Feather est de 50 ms.
Le turnstile est une animation qui possède quatre variations :
  • On arrive sur une nouvelle page ; la page apparaît par derrière et s’arrête. C’est le Turnstile Forward in.
  • On sort de cette page pour une autre page ; la page courante disparaît par devant. C’est le Turnstile Forward out.
  • On revient de la nouvelle page sur la page d’avant ; la page précédente revient de devant et s’arrête. C’est le Turnstile Backward in.
  • On sort de l’application ; la page s’en va par derrière. C’est le Turnstile Backward out.

Spécifications

Nom Mouvement Durée Interpolation
Forward in -80 à 0 sur l’axe Y (avec centre de rotation en X à 0) 350 ms Exponentiel 6 (EaseOut)
Forward out 0 à 50 sur l’axe Y 250 ms Exponentiel 6 (EaseIn)
Backward in 50 à 0 sur l’axe Y 350 ms Exponentiel 6 (EaseOut)
Backward out 0 à -80 sur l’axe Y 250 ms Exponentiel 6 (EaseIn)

Conseils

Le Turnstile (et Turnstile Feather) est l’animation reine de Windows Phone 7 et donne un rendu magnifique, d’autant plus que les projections sont accélérées par le GPU. Elle est faite pour les animations d’entrée et de sortie d’application et pour la navigation dans les pages de l’application.
Attention cependant aux chutes de performances si vous utiliser cet effet sur des pages qui contiennent trop d’éléments, ou qui ne sont pas mise en cache sur le GPU (par exemple lors de l’utilisation de masque d’opacité).

Slide

Description

Le slide est un glissement de la page entière qui peut être lié à un fondu ou non (Slide / Slide and Fade). Il est utilisé pour symboliser la création d’un nouvel élément. Il peut être s’effectuer sur les côtés ou en haut / en bas. Deux états le caractérisent, l’apparition (slide in) et la disparition (slide out).

Spécifications

Nom Mouvement Durée Interpolation
Slide in Mouvement de 150 px dans la direction voulue 350 ms Exponentiel 6 (EaseOut)
Slide out Idem 250 ms Exponentiel 6 (EaseIn)
Slide and fade in Idem 350 ms Exponentiel 6 (EaseOut)
Slide and fade out Idem 250 ms Exponentiel 6 (EaseIn)

Conseils

Le slide est une animation qui est utilisée lors de la création d’une nouvelle donnée (exemple nouveau mail, nouveau contact, etc.) Elle est très simple et rend généralement bien. On peut également jouer sur les directions pour ajouter du sens : par exemple lors de la création d’un nouveau mail, si l’on annule la création du mail le slide s’effectue vers le bas (je jette mon mail à la poubelle) et si on envoie le mail le slide s’effectue vers le haut (j’envoie mon mail vers le server).

Continuum

Description

L’effet continuum permet de suivre la transition depuis une liste, vers une page de description de l’élément que l’on vient de sélectionner. Il est utilisé par exemple dans le Marketplace, lorsque l’on sélectionne une application et que l’on arrive sur la page descriptive de l’application.
Lorsque l’on clique sur l’élément, cet élément va avoir un mouvement courbe qui sort de l’écran (Forward out) et après la transition sur la page suivante, ce même élément va apparaître depuis l’extrémité de l’écran pour se placer en haut de l’écran, toujours suivant un mouvement courbe (Forward in). Quand on appuiera sur la touche back, la page entière disparaît (Backward out), et de retour sur la page précédente, l’élément réapparait du côté et revient à sa place dans la liste (Backward in).

Spécifications

Nom Mouvement Durée Interpolation
Forward out L’élément sélectionné se déplace de 73px vers le bas et de 225px sur le côté droit. La page glisse vers le bas de 70px et disparaît (opacité 0%) 150 ms Exponentiel 6 (EaseOut)
Forward in La page glisse vers le haut de 150 px. L’élément quant à lui arrive du coté de 130 px et descend de 70 px. 150 ms Exponentiel 6

(EaseOut)
Backward out La page effectue un glissement de 150 px et disparaît en même temps (Opacité 0%) 150 ms Exponentiel 6 (EaseIn)
Backward in L’élément revient de 70 px depuis la gauche. 150 ms Exponentiel 6 (EaseOut)

Conseils

Le continuum est parfait pour relier deux pages par un élément spécifique. Il faut juste faire en sorte que c’est cet élément qui se déplace de la première à la seconde page et inversement.

Swivel

Description

L’effet swivel est un effet qui montre l’apparition d’une fenêtre modale à l’écran. C’est une projection sur l’axe X. On peut en voir une application lors d’un appel entrant (apparition) et lorsque l’appel est terminé (disparition).

Spécifications

Nom Mouvement Durée Interpolation
Apparition -45 à 0 sur l’axe X (avec centre de rotation en Y à 0,5) 350 ms Exponentiel 6 (EaseOut)
Disparition 0 à 60 sur l’axe X 250 ms Exponentiel 6 (EaseIn)

Conseils

Les angles utilisés sont volontairement inférieurs à 90° pour donner une impression de vitesse. Pensez à mettre la visibilité à Collapsed dès que l’animation est terminée, ou votre rendu paraîtra chaotique. Cet effet est à réserver aux éléments qui apparaissent au-dessus des pages normales, qu’ils soient en plein écran ou non.

Rotate

Description

La rotation est l’effet par défaut lors d’un changement d’orientation dans le système. Il peut se faire du mode portrait au mode paysage ou du mode paysage au mode portrait.

Spécifications

Nom Mouvement Durée Interpolation
Rotation gauche (respectivement droite) 0 à -90 (respectivement -90 à 0) sur l’axe Z 500 ms Exponentiel 6 (EaseInOut)

Conseils

La rotation est l’effet à utiliser en cas de changement d’orientation. Par cohérence, vous pouvez également utiliser ces caractéristiques de durée et d’interpolation pour n’importe quelle rotation au sein de votre application.

Implémentation

Il est curieux que Microsoft n’ai pas encore proposé de code samples pour gérer les animations tout en étant cohérent avec le reste du système. Heureusement plusieurs l’ont déjà fait. C’est le cas de Clarity Consulting qui propose dans leur article une classe abstraite AnimatedBasePage qui gère les transitions. C’est également le cas de Telerik qui propose depuis peu un ensemble de contrôles pour Windows Phone.
Avec les spécifications, vous pouvez également créer ces animations, soit en XAML, soit en code et les appeler dans les différents évènements de la page. Par exemple, gérer les évènements NavigatedTo, NavigatingFrom et OnBackKeyPress vous permettra de créer dynamiquement des instances des différents storyboards et de jouer les animations.
Implémenter les animations de Windows Phone 7 peut être somme toute un peu compliqué, mais la valeur ajoutée est au rendez-vous, car cela permet à vos applications de se comporter comme le reste du système, et il faut avouer que les animations de WP7 ont vraiment un style unique !

Windows Phone 7 Silverlight Toolkit et les animations

Microsoft a justement attendu ce jour pour dévoiler la mise à jour de Novembre du WP7 Silverlight Toolkit qui contient… les classes qui vont vous aider à mettre en place les animations dans vos applications Windows Phone 7 ! Les nouvelles API ont l’air assez faciles à utiliser; il faut tout d’abord remplacer la RootFrame dans le App.xaml.cs par un TransitionFrame. Ensuite on pourra définir des transitions en XAML comme ceci :
<toolkit:TransitionService.NavigationInTransition>
 <toolkit:NavigationInTransition>
 <toolkit:NavigationInTransition.Backward>
 <toolkit:TurnstileTransition Mode="BackwardIn"/>
 </toolkit:NavigationInTransition.Backward>
 <toolkit:NavigationInTransition.Forward>
 <toolkit:TurnstileTransition Mode="ForwardIn"/>
 </toolkit:NavigationInTransition.Forward>
 </toolkit:NavigationInTransition>
</toolkit:TransitionService.NavigationInTransition>
Plus d’informations sur le Toolkit 2ème édition se trouvent sur le blog de David Anson !

Utiliser et modifier les couleurs de thèmes sous Windows Phone 7

Dans un précédent article, j’ai décrit comment utiliser les ressources de Windows Phone 7 pour accorder les polices en tailles, graisse, et couleur avec le reste du système. Dans cet article je vais me focaliser plus particulièrement sur les couleurs. Nous verrons ainsi comment utiliser les couleurs du système dans ses applications et comment les surcharger.

Utiliser les couleurs

Comme les tailles de police, les couleurs et brushes sont mises dans des fichiers de ressources présents dans le téléphone. Elles sont toutes définies par des clés pour y accéder en XAML via l’extension Propriete= »{StaticResource CléDeRessource} » ou en code via la propriété Application.Current.Resources[« CléDeRessource »].
Pour rappelle une Brush peut être une couleur, un dégradé ou bien une image. Toutes ces Brush sont de simples couleurs car les dégradés ne sont pas conseillés dans les guidelines de Metro étant donné les limitations des écrans 16bpp. Voici une liste non exhaustive de brushes qui peuvent être utilisées dans vos applications.
Clé de ressource
Utilisation
PhoneAccentBrush
Brush d’accentuation définie par le thème.
PhoneForegroundBrush
Brush utilisée pour les éléments de premier plan tels que le texte ou les icônes.
PhoneBackgroundBrush
Brush utilisée pour les éléments d’arrière-plan.
PhoneContrastBackgroundBrush
Brush de fond utilisée pour les éléments à mettre en contraste. Par exemple le fond des menus contextuels.
PhoneContrastForegroundBrush
Brush de premier plan utilisée pour les éléments à mettre en contraste. Par exemple les textes des menus contextuels.
PhoneDisabledBrush
Brush des éléments désactivés (par exemple un bouton désactivé)
PhoneSubtleBrush
Brush partiellement transparente qui permet de mettre en retrait des éléments visuels moins importants.
PhoneBorderBrush
Brush de bordure des contrôles TextBox, CheckBox, PasswordBox, et RadioButton.
PhoneSemitransparentBrush
Brush presque transparente permettant de faire ressortir des éléments de couleurs similaires (par exemple du texte blanc sur une image claire).
Ces brushes permettent d’une part de pouvoir faire des variations de couleurs tout en restant dans l’univers de l’utilisateur. Elles permettent également, si vous créez des contrôles personnalisés de conserver la cohérence visuelle avec le reste de votre application.

Modifier localement les ressources

Un autre aspect très intéressant de ces ressources est qu’elles sont naturellement utilisées par l’ensemble des contrôles Silverlight. On peut donc créer des applications cohérentes visuellement, en ne changeant que très peu de chose. Suivez le guide :
  1. Allez dans %ProgramFiles%\Microsoft SDKs\Windows Phone\v7.0\Design
  2. Copier le fichier ThemeResources.xaml dans votre projet
  3. Aller dans votre App.xaml
  4. Ajouter un ResourceDictionary dans les ressources de votre Application :

<ResourceDictionary>
  <ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="Themes/ThemeResources.xaml" />
  </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>

Vous pouvez à présent modifier localement les brushes afin de changer les couleurs de tous les éléments déjà présents. Par exemple le changement des ressources PhoneForegroundBrush, PhoneBackgroundBrush et et PhoneSubtleBrush permettent d’avoir une infinité de variations.

Accorder les images au thème

Pouvoir changer les couleurs du texte et du fond est une chose, mais dans une application avec des logos, cela ne suffit pas. J’ai vu pas plus tard qu’aujourd’hui une technique très intéressantes permettant d’accorder également les icônes aux couleurs système, que je me permets de reprendre. Source: http://advertboy.wordpress.com/2010/09/25/using-an-image-as-a-mask-so-that-wp7-themes-are-honoured/
Pour faire simple cette technique consiste à mettre un contrôle, par exemple un bouton si on veut un déclencher une action, ou un Border si on ne veut pas d’interaction. On va mettre tout d’abord sa couleur de fond à la couleur souhaité, disons PhoneForegroundBrush. On va ensuite créer une ImageBrush avec notre logo. On va enfin mettre cette ImageBrush comme OpacityMask de notre premier élément.
<Border
  Background="{StaticResource PhoneForegroundBrush}"
  Width="30"
  Height="30"
  VerticalAlignment="Center">
  <Border.OpacityMask>
    <ImageBrush Stretch="Uniform" ImageSource="restaurant.png"/>
  </Border.OpacityMask>
</Border>
Résultat, nous avons créé un icône dont la couleur dépend du thème choisi. En action cela donne ça :
Ce que j’aime particulièrement dans cette technique est que cela peut marcher avec n’importe quelle couleur, y compris celles d’un thème modifié comme dans l’exemple précédent ou de la couleur d’accent par exemple.
Seul problème qui subsiste : admettons que vous avez une image qui n’est pas monochrome mais que voulez quand même changer selon que l’utilisateur utilise votre application en thème clair ou sombre. C’est là que vont servir les ressources PhoneDarkThemeVisibility et PhoneLightThemeVisibility (ainsi que PhoneDarkThemeOpacity et PhoneLightThemeOpacity). On va grâce à ses objets, pouvoir mettre deux images l’une sur l’autre. La visibilité de chaque image sera liée à la ressource qui lui correspond, à l’aide d’un converter qui affichera l’une ou l’autre selon le thème.
Les thèmes sont donc particulièrement pratiques et utiles sous WP7. Par défaut ils permettent de garder une cohérence visuelle au sein du système et quand on les surcharge, ils peuvent permettre de respecter une charte graphique pour une cohérence visuelle au sein de l’application elle-même.

Pour avoir une Tile plus native

Pour terminer, une astuce toute fraiche pour que les Tiles de vos application utilisent la couleur de thème que vos utilisateurs ont choisi : au lieu de mettre un fond, mettez un fond transparent et sauvegarder votre image en png avec support de la transparence. Et voilà, votre application n’a jamais paru aussi native !

La typographie dans Metro

Comme je l’avais abordé dans mon précédent article sur Metro, le langage graphique de Windows Phone 7, la typographie est un élément clé de la conception des applications. Les éléments textuels servent à afficher des informations mais font également partie de la décoration des applications. Dans cet article je couvrirai les différents cas d’utilisation de typographie et les recommandations de Microsoft sur les polices, graisses et casses pour que vos applications paraissent le plus native possible !

La police de caractères de Metro

Windows Phone 7 intègre par défaut la police de caractère Segoe WP qui est utilisée dans tout le reste du système. Quand vous concevez une application, c’est également cette police de caractère qui est utilisée par défaut. Vous pouvez intégrer vos propres polices, et les polices standards telles qu’Arial, Times, etc. sont également disponibles mais dans le cas d’une application il est fortement conseillé de rester sur Segoe WP car Metro est fortement basé dessus. Dans le cas d’un jeu XNA en revanche, vous pouvez utiliser n’importe quelle police si elle va dans l’esprit de votre jeu.

La police Segoe WP se décline en 6 variations de graisses, du plus au moins épais :

  • Segoe WP Black
  • Segoe WP Bold
  • Segoe WP SemiBold
  • Segoe WP Regular (par défaut)
  • Segoe WP SemiLight
  • Segoe WP Light

Pour une raison que j’ignore, le guide « UI Design and Interaction Guide for Windows Phone 7 », véritable guide sur l’interface Metro, ne mentionne pas Segoe WP Light dans les différents styles de Segoe WP, mais on peut quand même l’utiliser dans ses interfaces. A savoir après si cela est « bien » au sens de Metro…

Les titres de page ou de sections dans les applications Windows Phone 7 sont généralement en Segoe WP SemiLight. Comme vous pouvez le remarquer, j’ai mis tout le titre en bas de casse. C’est notre première règle typographique de Metro : quand vous utilisez du Segoe WP SemiLight ou Light, tout le texte doit être en bas de casse.

Autre constatation, certains éléments sont entièrement en bas de casse tandis que d’autre sont entièrement en capitales : c’est par exemple le cas du titre de l’application, situé au-dessus du titre de page, ou bien de tout élément en Segoe WP Black.

Comment utiliser les ressources du système

Pour ce qui est des tailles, Metro recommande de ne pas utiliser de taille de police en dessous de 15 pts. Vous pouvez choisir vous-même les tailles de vos blocs de texte, mais plutôt que de mettre des tailles en valeur absolue, vous pouvez également utiliser dans vos applications les styles prédéfinis de Metro. Ces tailles sont contenues dans un fichier de ressources ; vous pouvez donc y accéder par l’extension StaticResource. Par exemple :

<TextBlock Foreground="{StaticResource PhoneAccentBrush}" FontFamily="Segoe WP" FontSize="{StaticResource PhoneFontSizeMediumLarge}" Text="important notice in segoe wp bold" FontWeight="Bold"/>

Le tableau ci-dessous (extrait de la MSDN library), récapitule toutes les tailles de police du fichier de ressources Metro. Notez bien qu’elle est donnée en point et non en pixel. Pour rappel, un point est égal à 1/72ème de pouce alors que l’unité de mesure de la police dans Silverlight est égale à 1/96ème de pouce, la conversion pour passer de points à pixel est donc de 96/72 soit 4/3.

Nom (clé dans le dictionnaire des ressources) Définition Taille
PhoneFontSizeSmall Petite police 14 pts (18,666666 px)
PhoneFontSizeNormal Police normale 15 pts (20 px)
PhoneFontSizeMedium Police moyenne 17 pts (22,666666 px)
PhoneFontSizeMediumLarge Police assez grande 19 pts (25,333333 px)
PhoneFontSizeLarge Police grande 24 pts (32 px)
PhoneFontSizeExtraLarge Police très grande 32 pts (42,666666 px)
PhoneFontSizeExtraExtraLarge Police très très grande 54 pts (72 px)
PhoneFontSizeHuge Police énorme 140 pts (186,666666 px)

De la même manière on peut utiliser le fichier de ressources pour les brushes, couleurs, polices, et marges. Par exemple on peut utiliser comme couleur de texte, la couleur de thème choisie par l’utilisateur. Cela permet de garder l’utilisateur dans son univers, et d’accentuer une phrase donnée. Toutes les clés de ressources et leur description sont accessibles sur la MSDN library à l’adresse suivante : http://msdn.microsoft.com/en-us/library/ff769552(VS.92).aspx

Enfin, sont également disponibles des styles de TextBlock prêt à être utilisés pour remplir certaines fonctions définies, telles que le titre d’une page. Dans ce cas, vous n’avez qu’à remplir la propriété Style. Par exemple :

<TextBlock x:Name="PageTitle" Text="semi light"  Style="{StaticResource PhoneTextTitle1Style}" />

Le tableau suivant (toujours issu de la même source) récapitule tous les Styles de TextBlock disponibles.

Name Description
PhoneTextBlockBase FontFamily: PhoneFontFamilyNormal
FontSize: PhoneFontSizeSmall

Foreground: PhoneTextBoxBrush

Margin: PhoneHorizontalMargin

PhoneTextNormalStyle FontFamily: PhoneFontFamilyNormal
FontSize: PhoneFontSizeNormal

Foreground: PhoneForegroundBrush

PhoneTextTitle1Style FontFamily: PhoneFontFamilySemiLight
FontSize: PhoneFontSizeExtraExtraLarge

Foreground: PhoneForegroundBrush

PhoneTextTitle2Style FontFamily: PhoneFontFamilySemiLight
FontSize: PhoneFontSizeLarge

Foreground: PhoneForegroundBrush

PhoneTextTitle3Style FontFamily: PhoneFontFamilySemiLight
FontSize: PhoneFontSizeMedium

Foreground: PhoneForegroundBrush

PhoneTextLargeStyle FontFamily: PhoneFontFamilySemiLight
FontSize: PhoneFontSizeLarge

Foreground: PhoneForegroundBrush

PhoneTextExtraLargeStyle FontFamily: PhoneFontFamilySemiLight
FontSize: PhoneFontSizeExtraLarge

Foreground: PhoneForegroundBrush

PhoneTextGroupHeaderStyle FontFamily: PhoneFontFamilySemiLight
FontSize: PhoneFontSizeLarge

Foreground: PhoneSubtleBrush

PhoneTextSmallStyle FontFamily: PhoneFontFamilyNormal
FontSize: PhoneFontSizeSmall

Foreground: PhoneSubtleBrush

PhoneTextContrastStyle FontFamily: PhoneFontFamilySemiBold
FontSize: PhoneFontSizeNormal

Foreground: PhoneContrastForegroundBrush

PhoneTextAccentStyle FontFamily: PhoneFontFamilySemiBold
FontSize: PhoneFontSizeNormal

Foreground: PhoneAccentBrush

Les nouveaux contrôles des outils de développement

Le 16 septembre sortiront les outils de développement de Windows Phone 7 en RTM. Parmi les nouveautés, on pourra trouver entre autres les fameux contrôles Panorama et Pivot que tout le monde attend. Jeff Wilcox a écrit sur son blog un aperçu de ces deux nouveaux contrôles : http://www.jeff.wilcox.name/2010/08/looking-ahead-at-panorama-and-pivot/

Dans les deux captures on remarque l’utilisation de la police Segoe WP SemiLight et toujours en bas de casse.

1 Le contrôle Panorama

2 Le contrôle Pivot

Pour conclure, on peut remarquer que Metro implique quelques règles typographiques assez particulières, voire déconcertantes pour certaines personnes. Il ne faut pas les prendre à la légère car c’est ce genre de détails subtils qui font la richesse de Metro. Soignez donc vos textes, et utilisez dès que vous le pouvez les ressources du système pour rendre votre application aussi cohérente que possible !

Les dégradés et Windows Phone 7

Dans Silverlight, il est très simple de mettre un dégradé comme fond d’un contrôle. Grâce aux classes LinearGradientBrush et RadialGradientBrush, en quelques lignes de XAML on obtient un dégradé linéaire ou radial. Seulement voilà, depuis la sortie des outils de développement de Juillet (version beta), les dégradés dans les applications Windows Phone 7 apparaissent très mal. En effet on voit dans l’émulateur, l’apparition de bandes à l’intérieur du dégradé, et ce bien que le code n’ait pas changé et que le rendu soit parfait dans Blend / Visual Studio… Pourquoi ?

Pourquoi ces bandes ?

Le problème vient du fait que Silverlight fait son dégradé en utilisant plus de couleur qu’un écran 16 bpp (bits par pixel) peut en afficher. Comme rien n’oblige les téléphones Windows Phone 7 à avoir des écrans 32 bpp, je suppose que l’équipe de développement de l’émulateur a préféré mettre l’émulateur en 16 bpp pour aider les développeurs à concevoir des applications qui fonctionnent quel que soit le matériel. Ce problème n’est donc pas lié à Windows Phone 7 lui-même, et on le retrouve sur d’autres plateformes. Voyons maintenant comment contourner ce problème.

Comment les faire disparaître ?

Une solution assez communément proposée est de transposer le dégradé en image en y ajoutant un fin bruitage. Cela casse la linéarité du dégradé et permet d’avoir des résultats assez satisfaisant.

Pour cela ouvrez votre outil graphique préféré (par exemple paint.net) et ajoutez du bruit. Tout est question de dosage, pour éviter de dégrader trop l’image, tout en ayant réellement un effet. Changez ensuite votre LinearGradientBrush par un ImageBrush contenant votre image et mettez le Stretch à Fill pour que votre dégradé s’étende sur tout son contenu. Et voilà !

Qu’en dit Metro ?

Dans le style Metro, on utilise principalement des couleurs unies et du contenu (images) pour les fonds des pages et des contrôles, c’est pourquoi cette restriction devrait être assez peu impactante pour peu que vous ayez respecté les consignes de Metro à la lettre. Sinon cette manipulation vous sauvera peut être la mise.

Qu’est-ce que Metro ?

J’avais parlé des raisons qui me poussent à écrire sur Windows Phone 7. Metro, l’expérience utilisateur novatrice de Windows Phone 7 en fait partie intégrante. Avant de se pencher sur ce qu’est Metro, regardons tout de suite ce que n’est pas Metro. Metro n’est pas :

  1. Une technologie / une application.
  2. Un composant de Windows Phone 7.
  3. Un Framework.

Qu’est-ce que Metro ?

Dans ce cas qu’est-ce que Metro ? C’est un ensemble de principes sur lesquels sont basée des technologies et des applications. Windows Phone n’est pas le premier système à l’intégrer, étant donné que Metro a été pensé à l’origine pour Windows Media Center. Avant de rentrer dans les détails, prenons quelques exemples d’interfaces construites sur ce modèle.

Comme je l’ai dit, Metro a été pensé pour Windows Media Center. De cet exemple on voit apparaître quelque similitude avec l’interface de Windows Phone 7, en particulier la typographie (la police de caractère Segoe faisant partie intégrante de l’interface Metro). On voit également que le contenu de l’utilisateur (en l’occurrence la vidéo en train d’être visionnée) sert de graphisme pour l’application tout comme les photos sur Windows Phone 7 servent de fond pour le hub photo.

La nouvelle version du Dashboard de la Xbox360 qui arrivera à l’automne avec Microsoft Kinect est un autre exemple d’interface purement Metro, claire avec sa disposition organisée et sa typographie caractéristique. Tout comme les « carreaux » de l’écran d’accueil de Windows Phone 7, on retrouve du contenu à l’intérieur de rectangles.

Le Zune HD a posé les bases du concept d’un certain nombre de composants de Windows Phone 7. En particulier le Pivot, ce composant central de l’interface utilisateur de Windows Phone 7 est apparu sur Zune HD. En outre les règles de typographie, les couleurs et l’iconographie de Windows Phone 7 sont eux aussi issu du baladeur de Microsoft.

Quels sont les principes de Metro ?

Microsoft défini Metro comme un langage de conception, et comme tous langage il répond donc à un certain nombre de règles. Voyons à présent quelles sont ces règles.

Clair, fluide, rapide

L’application doit être claire et intuitive. L’interface utilise les marges pour combler l’espace sans être surchargée. Chaque écran se concentre sur sa tâche principale, évitez donc au maximum les écrans fourre-tout. Le but est de faire beaucoup de chose à partir de très peu d’éléments et de garder toujours ce côté organisé.

L’utilisateur ne doit pas avoir le temps d’attendre l’application, même lors de tâches de longue durée. Il doit y avoir toujours à l’écran quelque chose pour attirer l’attention de l’utilisateur (ex : ProgressBar).

Typographie, iconographie, contenu

Le style de Metro serait sans doute très différent sans sa police de caractères Segoe UI (Segoe WP sous Windows Phone 7). Le texte dans les applications Windows Phone 7 ne sert pas qu’à afficher des contenus, il fait partie de la décoration de l’application au même rang que les images et les icônes.

L’iconographie est également au cœur du style Metro. Ils permettent de faire passer des messages sans la barrière de la langue. Le nom « Metro » vient d’ailleurs de la signalétique des transports, où les indications très sobres et directes doivent permettre à tous les voyageurs de trouver leur chemin. Les applications Metro doivent donc de la même manière permettre aux utilisateurs de trouver leur chemin dans les écrans de l’application. Les icônes doivent êtres simples et sont le plus souvent monochromes pour profiter du contraste avec la couleur du fond sur lequel ils sont implantés.

Enfin le contenu est primaire dans l’application Metro. Cela permet à une application d’être hautement personnalisé et donc perçu différemment par ses multiples utilisateurs. Il faut donc réduire au maximum le nombre de contrôles qui ne sont pas du contenu.

Tactile, dynamique, en mouvement

Metro rassemble aussi un certain nombre de recommandation sur l’aspect tactile de l’application, en particulier la taille des éléments tactiles. En effet sur un système qui se veut complètement utilisable aux doigts et bénéficiant d’au moins 4 points simultanément, toute l’interface doit être interactive. Lors des interactivités, l’application doit montrer immédiatement que les mouvements sont pris en compte.

Enfin les transitions et animations ont un grand rôle à jouer dans l’application Metro : les transitions permettent de distraire l’utilisateur pendant le chargement des composants de l’application. Les animations permettent de simuler une interaction physique avec l’utilisateur.

Comment concevoir une application Metro ?

Microsoft a rendu disponible un document qui explique un grand nombre de best practices sur la conception d’application pour Windows Phone 7. Avant de vous lancer dans le développement je vous conseille de lire attentivement ce guide. Vous pouvez télécharger le Windows Phone UI Design and Interaction Guide à l’adresse suivante : http://go.microsoft.com/?linkid=9713252. Vous pouvez en outre lire le document explicatif du concept de Metro : http://go.microsoft.com/fwlink/?LinkID=189338

Ensuite il va vous falloir penser à comment votre idée d’application peut se traduire en langage Metro. Suivez bien les recommandations du guide, elles permettent à votre application d’être cohérente avec le système lui-même et avec les autres applications.

Sachez cependant qu’il n’y a pas une seule façon de faire une application sur un thème donnée qui soit conforme au style. Par exemple Microsoft a créé deux applications météo bien distinctes avec le style Metro ; Metro ne doit donc pas être un frein à la créativité mais un guide.

N’oubliez pas non plus que l’utilisateur doit être au centre de l’application. Essayer de penser en tant qu’utilisateur afin de faire les meilleurs choix pour les utilisateurs. L’utilisateur appréciera également si votre application se plie à sa personnalité et à son contenu. La personnalisation est donc un élément clé à ne pas oublier pendant la conception.

Une fois votre idée fixée sur le papier, vous pouvez passer au développement. N’oubliez pas, les contrôles de Silverlight pour Windows Phone 7 ont été entièrement stylisés pour respecter le style Metro. Cela ne vous empêche pas d’éditer leur aspect visuel, mais tâchez de rester dans l’esprit Metro, en évitant par exemple les boutons chromés ou les contrôles avec beaucoup de nuances de couleurs.

Microsoft a créé un style graphique attrayant basé sur un certain nombre de critères. En normalisant ces critères dans le langage de conception Metro, l’opportunité est offerte aux développeurs de créer des applications qui vont en quelque sorte étendre Windows Phone 7. Une chose est sûre, le prochain système d’exploitation mobile de Microsoft va offrir une expérience utilisateur particulièrement soignée et cohérente.