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…

Première application sur le marketplace !

Voilà, malgré un certain temps d’absence depuis le dernier article (mais rassurez-vous, un prochain article est en préparation), j’ai eu le temps de réaliser une petite application gratuite, plus pour m’amuser que pour créer la killer-app du siècle, que j’ai mise sur le marketplace. Il s’agit de « Fête du jour » pour voir quels prénoms sont fêtés un jour donné, et inversement voir à quelles dates sont fêtés vos proches. Voilà le lien de téléchargement Zune, ainsi que quelques screens ! N’hésitez pas à commenter pour me donner votre avis sur l’application !

Télécharger pour Windows Phone 7

EDIT 02/02/02 : Mon application est aujourd’hui dans les applications recommandées par Microsoft ! Champagne !

Télécharger pour Windows Phone 7