Pierre's Embedded and Mobile Blog

Soulevons le capot des systèmes embarqués et mobiles

July, 2010

Posts
  • Pierre's Embedded and Mobile Blog

    [Windows Phone 7] Vous, votre application, une page facebook et un jury… présidé par Steve Ballmer :)

    • 0 Comments

    Pas de lancement de plateforme mobile sans un concours – c’est quasiment devenue une institution pour encourager les développeurs à créer des applications… Windows Phone 7 n’échappe pas à la règle. Sur ce concours, nous voulons donner un maximum de visibilité aux applications qui seront créées d’ici le lancement et particulièrement de la visibilité face aux investisseurs… et pas des petits noms: Steve Ballmer, Antoine Granjon (Vente-privée.com), Ouriel Ohayon (AppsFire et le fond Isai), Marc Simoncini (Meetic et le fond Jaina), Bruno Vanryb (Avanquest) et Pierre-Olivier Carles (Kipost et Labotec)….

    Mais avant de vous offrir 2 minutes pour les convaincre, et vous payer une visibilité de malade, il faudra se faire sélectionner parmi tous les concurrents à travers le nombre de “like” sur la page Facebook developpeurs de la vidéo de votre application.

    Donc au boulot, tout est expliqué sur cette page!

    Et pour ceux qui veulent tester leur application sur des terminaux, contactez-moi :)

  • Pierre's Embedded and Mobile Blog

    [Windows Phone 7] Adopter ou ne pas adopter “Metro”?

    • 0 Comments

    Indubitablement Windows Phone 7 arrive sur le marché avec une approche particulière de l’ergonomie du téléphone, avec la mission avouée de “placer l’utilisateur au centre du téléphone”. Loin de la liste d’icône qu’on peut retrouver chez certains concurrents (bien qu’il y en ait une quand même), l’écran d’accueil (start screen) et les hubs (ou panoramas) souhaitent glorifier le contenu, se débarrassant de tout élément “inutile” d’interface graphique. Quand on est développeur, on entend les designers parler de choses bizarres et leur donner une utilité ou une mission incompréhensible: qu’est-ce que “l’espace négatif”? comment “célébrer la typographie”? comment fait-on pour “délecter l’utilisateur par l’usage du mouvement”?!

    Qu’on aime ou qu’on déteste les idées qui construisent l’interface de Windows Phone 7, il faut se familiariser avec son “langage de design”, nom de code Metro. Même si l’on peut choisir de l’adopter complètement, d’en récupérer une partie des idées ou d’ignorer ses préceptes (Silverlight permet de faire exactement ce qu’on veut avec les éléments graphiques et ergonomiques) l’utilisateur va s’habituer à l’ergonomie de son Windows Phone 7 : ne pas porter attention, ou mal comprendre “Metro”, c’est risquer de créer des glitchs, des incohérences, des ruptures dans le processus de compréhension ou de navigation dans l’interface: dans le pire des cas, l’utilisateur est dérouté par votre application et ne l’utilise pas, voire l’évalue avec une mauvaise note dans le Marketplace.

    Pour autant nous n’avons pas tous la chance de travailler avec des designers, et en tant que développeurs nous avons rarement le bagage culturel et technique, l’état d’esprit, le background pour comprendre et concevoir une “interface naturelle”, qui est le propre de Windows Phone 7. C’est pour ça que l’équipe des designers Windows Phone 7 publie de nombreux documents et webcasts à propos des principes de “Metro”. Il faut s’astreindre à les regarder, les étudier, y réfléchir et les revoir encore, car c’est dans ces ressources qu’on trouve les petites phrases, les éléments clefs qui nous aident à comprendre ce qu’on peut faire bien ou mal. Voici quelques-unes de ces ressources indispensables:

    Voici quelques exemples de “prises de conscience” que j’ai eu en regardant ces webcasts et en repassant sur les documents:

    On ne doit concevoir le “panorama” de son application qu’en dernière étape! Le panorama est un moyen d’encourager l’utilisateur à plonger dans l’application, et ne doit présenter que des bribes d’informations qui résonnent naturellement auprès de l’utilisateur – les derniers usages qu’il a fait de l’application, le contenu récemment publié, les images les plus consultées… A concevoir le panorama en premier, on le surcharge et on rend l’application incohérente: c’est comme si on voulait créer un journal et qu’on commençait par concevoir la couverture! D’abord on fait les articles, ensuite on choisit ce qu’on met en couv’!

    Le contrôle pivot vous permet de présenter de l’information sous forme “classée”: que ce soit la même information ou une information différente: par exemple des points d’intérêts sous forme de liste dans une page du pivot, et sur une carte dans une autre page. N’hésitez pas à proposer plusieurs vues de la même information: votre application n’en sera que plus riche et vous laisserez à l’utilisateur le choix de l’usage.

    Tout élément de mon interface est “touchable”: car l’écran entier est tactile: chaque interaction de l’utilisateur avec son écran doit lui renvoyer un feedback: que ce soit pour se déplacer dans une page, pour agrandir une photo ou pour mettre à jour un statut, il faut pour chaque élément se poser la question “pourquoi l’utilisateur voudrait-il toucher cet élément? quel doit être le feedback?”

    Ce qui est évident à l’usage (le téléphone en main) n’est pas forcément visuellement évident à première vue: par exemple, le vide est une information en lui-même… Entendu à maintes reprises à propos de l’écran d’accueil: “pourquoi laisser une bande noire sur le coté droit de l’écran d’accueil? c’est de l’espace perdu!!”. Et après avoir laissé l’utilisateur toucher le téléphone “ha mais.. il y a quelque chose à droite de cette zone!” si cette zone non utilisée n’était pas là, comment naviguerait-on vers la liste d’icône? Il faut comprendre que Metro, c’est une interface “en mouvement” et qu’une vue statique de celle-ci (comme de votre application) ne reflète pas forcément l’usage.

    Les transitions visuelles doivent être pensées “dans le sens du mouvement” : si par exemple l’utilisateur change de page en faisant un geste de la droite vers la gauche, alors l’animation doit suivre, immédiatement et sans délai, le geste de l’utilisateur, de la droite vers la gauche. Et le retour à la page précédente doit se faire avec une animation de la gauche vers la droite. Le dire parait une évidence mais à l’implémentation on retrouve de nombreux développeurs faire la même animation de changement de page que ce soit pour aller chercher une nouvelle information ou pour revenir en arrière. Dommage! Qu’une transition soit jolie, c’est bien, qu’elle soit en plus utile et qu’elle permette de se repérer dans l’interface, c’est mieux!!

    Et des exemples comme ça, il y en a à foison: bien espacer les éléments pour qu’ils soient facilement manipulable au doigt, utiliser le “hors champ” pour suggérer qu’il y a du contenu en dehors du formulaire (comme dans les panoramas) etc.

    Dernier point à propos de Metro – je faisais la démonstration de l’interface à une designer, comme d’habitude en expliquant chaque étape et le rôle des différents éléments graphiques, transitions, etc… jusqu’au moment ou elle m’a gentiment fait remarquer que je n’avais pas besoin de l’expliquer parce que c’était “naturel”. Je vous laisserai donc avec ça, et en paraphrasant Bill Buxton: quoi que vous fassiez pour votre interface, faites en sorte qu’elle soit “naturelle”!

Page 1 of 1 (2 items)