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…

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 !