mdevcon 2014

Le 7 et 8 mars dernier, avait lieu la mdevcon 2014. J'ai eu le privilège d'être choisi aux call for paper pour présenter une session sur l'expérience utilisateur Android : "My Android is not an iPhone like any others" et j'ai pu assister aux 2 jours de conférences. En voici le compte rendu...

1er jour : "Tutorial day"

Entre deux sessions typiquement iOS (Debuging avec XCode 5 et Core data), deux sessions plutôt Android (Google Maps et crash reporting), j'ai préféré me diriger vers 2 sessions transverses : "Mobile Protoyping" le matin et "Going Mobile with the Cloud" l'après-midi.

Mobile Prototyping

Donna Lichaw est venue de New York pour nous parler de mobile prototyping. Nous avons commencé par discuter du "why" du prototyping. Entre autre, cela permet de tester, affiner et valider un concept, avoir un feedback et les réactions des utilisateurs le plus vite possible, construire un MVP. Prototyper sur mobile a encore plus de sens selon elle. La navigation est extrêmement importante sur mobile, ainsi que le contenu des écrans qui doivent contenir l'essentiel. C'est aussi généralement plus cher à développer et surtout plus compliqué à corriger (elle parle notamment de l'App Store où la phase de validation par Apple est un frein). Mais au delà de tout ça, prototyper permet de rassembler toute l'équipe autour du produit, à condition que tout le monde participe. Aussi bien les designers que les développeurs, ou encore les managers et sponsors, tout le monde s'approprie le produit, ce qui facilitera la suite du projet.

Donna nous a ensuite décrit les différents types de prototype:

• Les storyboads qui permettent de définir l'interaction entre l'utilisateur et le système, les différentes étapes d'utilisation du produit. Cela s'apparente plus à une sorte de use case qu'à un prototype d'écran.
• Le paper prototyping qui permet de très rapidement dessiner des écrans sur papier. C'est très bien pour brainstormer et avoir les premiers feeedbacks pour un investissement faible (https://www.youtube.com/watch?v=GrV2SZuRPv0). Le but n'est pas de rentrer dans les détails, mais d'avoir une idée globale des différents écrans.
• Des maquettes imprimées. Si vous voulez quelque chose de plus raffiné/détaillé que le papier, vous pouvez commencer à utiliser des outils de mockup ou photoshop et les imprimer pour jouer avec. C'est déjà plus cher que le dessin mais cela permet d'avoir quelque chose de plus consistent à montrer à des utilisateurs.
• Vous avez aussi la possibilité d'afficher des maquettes sur l'écran du device (dans la galerie) afin d'évaluer le comportement des utilisateurs sur des vrais écrans sur un vrai mobile.
• Viennent ensuite les prototypes avec du code. On les utilisera plus souvent pour valider la faisabilité technique d'une fonctionnalité ou pour valider quelque chose de dynamique (animation).

Elle nous a ensuite donné quelques bonnes pratiques pour les interfaces mobiles. Adopter les conventions des systèmes: NavigationBar et TabBar sur iOS par exemple. De même pour les différents composants : préférez le DatePicker du système ou alors protoypez et testez votre version pour avoir du feedback. Concernant les gestures, les 3 plus communes sont le tap, le swipe et le flick (swipe rapide ou scroll). Les autres sont rarement connus et utilisés par les utilisateurs. Évitez donc les swipe à trois doigts ou autres actions cachées (long press, double tap, ...)

Enfin, elle nous a donné une liste d'outils utiles pour prototyper. Celui qui m'a particulièrement impressionné est flinto. Regardez cette petite demo pour vous en convaincre. Nous avons également regardé POP. Il s'agit d'une application Android et iOS qui permet de très rapidement définir la navigation de votre application:

• Soit vous faites du paper prototyping et vous prenez vos dessins en photo
• Soit vous pouvez utiliser vos maquettes.

Vous définissez ensuite des zones cliquables et les actions associées :

Pendant le TP qui a suivi, nous avons réalisé un prototype d'application de partage de photos en 20 minutes, dessins compris, grâce à cette application. D'autres outils ont été mentionnés comme Keynotopia, Axure, Appseed, Briefs, FluidUI, ...

Elle a conclu son tutorial en nous disant qu'il valait mieux (qu'elle préférait) prototyper sur mobile d'abord. Cela permet de se concentrer sur l'essentiel (1 action / écran) et de limiter les fonctionnalités. Cela a aussi l'avantage d'être testé facilement un peu partout. Et surtout, il est plus simple de scaler vers du web que l'inverse.

Une première matinée très intéressante ! Les slides sont disponibles ici.

Going Mobile with the Cloud

L'après midi, j'ai assisté au tutoriel de Chris Risner (Evangelist Windows Azure chez Microsoft). Je ne vais pas rentrer dans le détail de ce tutorial. Nous avons passé en revue une bonne partie des fonctionnalités d'Azure en l'intégrant à une application mobile. Chacun pouvait choisir sa plateforme et mettre en oeuvre le tuto également disponible sur github. C'était une bonne introduction au service de Microsoft que je n'avais jamais utilisé. Cela m'a permit de mettre en oeuvre pas mal de choses assez rapidement : manipulation des données, traitements côté serveur, notifications push, authentification... Les slides sont également disponibles sur le github.

Soirée speakers

Nous avons ensuite passé la soirée entre speakers : dîner sur un bateau sur les canaux, puis avant-première de 300 au cinéma. Merci aux organisateurs de tout ça.

Au final une première journée assez riche !

2ème jour : "Conference day"

Les conférences ont eu lieu dans un endroit assez exceptionnel, le théâtre Tuschinski.

Keynote : Make people care !

Rob Rhyne est co-fondateur de Martiancraft, auteur entre autre de Briefs, un des outils de prototyping que je citais plus haut. Sa keynote était dédiée au marketing des applications mobiles. Selon lui, il ne faut pas viser trop haut, vouloir devenir millionaire avec une application est dérisoire. Environ 1% des applications sur les stores engendrent plus de 90% des revenus.

Ainsi la première étape consiste à évaluer l'audience et le prix de son application. S'il y a environ 750 000 000 devices iOS sur le marché, il est clair qu'on ne peut pas espérer tous les atteindre. Sur ce nombre, environ 1% paye pour des applications (soit à l'achat, soit in-app), soit 7 500 000. Bien sûr, toutes ces personnes ne seront pas intéressés par votre application. Admettons qu'il y en ait 1% (75 000), c'est un nombre raisonnable mais il s'avère qu'en général il n'y a que 7.25% de ces 75 000 que vous puissiez atteindre, soit 5 625 personnes. Vous pouvez faire mieux bien sûr mais aussi moins bien. Il n'a cité aucune source pour ces chiffres, donc à prendre avec des pincettes. Mais cela me semble une bonne moyenne.

Il a ensuite parlé d'argent. Que souhaitez-vous gagner avec votre application ? 1 million de dollars ? Il faudra vendre votre application 177$. Ce n'est pas raisonnable. 250k ? 44$ l'application. Difficile! 100 000$ ? 17$ l'application. Encore bien au dessus des prix du marché ! Si vous descendez à 1$, vous obtiendrez 5625$. Ah non pardon 3937, Google et Apple en prenant 30 % au passage !

Bref, si vous souhaitez gagner plus, il va falloir atteindre plus de monde et pour ce faire, il faut du marketing ("Make people care") ! Plusieurs choses à faire :

• Parlez de votre application. Mais pas seulement de l'application en elle-même, parlez également de comment vous l'avez faite ? Cela permettra de ramener des développeurs, des geeks qui feront parler de votre app. N'attendez pas d'avoir publié l'application pour en parler. N'hésitez pas à contacter des journalistes ou des blogs afin qu'ils testent l'application en premiers et fassent de la pub.
• Partagez votre application avec les autres. Ne considérez pas que c'est VOTRE application et que personne ne doit vous dire comment la faire. Acceptez les feedbacks des utilisateurs !
• Troisième et dernier point, "keep going". Une fois l'application publiée, ne dormez pas sur vos lauriers. Corrigez les bugs, répondez aux utilisateurs et continuez d'en parler et de partager.

Plusieurs fois pendant la session il a dit : "You are special". C'est aussi avec cette note qu'il a conclu. En tant que développeurs mobiles, nous avons le pouvoir entre nos mains, la capacité de créer des choses et potentiellement de gagner pas mal d'argent avec.

Resistance is Futile: Google Glasses and the cyborg workforce of the future

Donna Lichaw, encore elle, nous a fait tout un parallèle entre la science fiction d'hier et la réalité d'aujourd'hui, comparant ainsi le premier téléphone mobile au moyen de communication utilisé par le Capitaine Kirk dans Star Trek.

Mais attention à l'effet Robocop (Frankenstein des temps modernes), la technologie doit exister pour nous aider, résoudre des problèmes que nous avons, pas simplement pour copier tel ou tel scénario SF.

Ainsi au sujet des Google Glasses, elle cite trois aspects qui permettent de dire que ce sera (c'est) utile :

• "J'ai un travail qui nécessite que mes mains soient libres pour le faire." Elle cite notamment Terminator qui avait besoin de ses mains pour dégommer tout le monde. Mais plus sérieusement, de nombreux métiers sont dans ce cas : les pilotes de chasse (qui ont déjà un affichage digital sur leur cockpit ou dans leur casque), les chirurgiens (qui font un hangout pour faire une démonstration ou avoir des conseils en temps réel), les pompiers, la police qui patrouille (cf. Robocop et la police de New York qui testent les lunettes actuellement).
• "Je suis mobile (à grande vitesse) et ne doit pas utiliser mes mains ou détourner le regard". Là encore les pilotes d'avions de chasse, mais à peu près n'importe quel pilote ou chauffeur ayant besoin d'aide à la navigation, peut en avoir l'utilité.
• "Je suis atteint d'un handicap et je veux pouvoir faire ce que les autres font". Par exemple aider les personnes mal voyantes à se déplacer.

Une session assez marrante et qui nous plonge dans un retour vers le futur assez flippant. Les slides sont disponibles ici.

Lightning fast mobile development at scale

Akhilesh Gupta, de LinkedIn, nous a présenté le processus de développement de leurs applications mobiles (iOS / Android / web) :

• Petite originalité pour commencer : Les vues sont construites à partir de JSON récupérés sur le serveur. Cela leur permet de faire évoluer plus rapidement leur IHM sans avoir à faire de mise à jour de l'application. De plus, pour certains éléments, ils utilisent les même templates JSON. Cela leur offre une certaine cohérence entre les différents écrans.
• D'autres pratiques sont plus communes : Intégration continue, dates de release fixes, crash reports.
• Concernant les tests des applications mobiles, ils utilisent appium.io, un outil de test d'interface cross-plateforme et basé sur Selenium (WebDriver JSON wire protocol). Côté serveur (sur node.js), ils n'a pas mentionné l'outil de test mais pour leurs tests d'intégration, ils sont passés de 30 minutes à 15 secondes d'exécution grâce à sepia. Cela leur permet d'exécuter les test unitaires et d'intégration à chaque build.
• Ils n'utilisent pas de feature branch sur leur SCM, tout est sur le trunk ! Ils font confiance à leur batterie de tests. Et lorsqu'il y a des fonctionnalités non terminées, ils utilisent le feature flipping, piloté par le serveur.
• Le feature flipping leur permet également de faire le l'A/B Testing (tester une fonctionnalité pour certains utilisateurs et une autre pour d'autres). Ils font plutôt cela pendant des phases de beta avec la console de dev Android et TestFlight sur iOS. Un article intéressant de LinkedIn sur l'A/B testing et les vues json.

Au final une session fort intéressante sur les pratiques d'un géant du web.

I can animate and so can you

Aussi incroyable que cela puisse paraître, c'est la première session exclusivement Android à laquelle j'ai assisté. Daniel Lew, qui nous avait déjà fait rêver à la Droidcon de Londres en octobre dernier, a remit le couvert en nous expliquant les grands principes et bonnes pratiques des animations sur Android. Pour info, Daniel Lew est développeur Android sur l'application Expedia, une application particulièrement réussie (A tester !). 4 choses importantes quand on veut animer des vues sur une application :

• Chaque animation est unique. Choisissez la bonne animation au bon moment et au bon endroit.
• Le code des animations n'est pas beau. Tant pis pour les amoureux du beau code !
• Pensez et implémentez les animations en premier. Cela sera plus simple et plus performant que d'essayer d'animer des choses qui n'ont pas été prévues pour.
• Animez pour des devices en Android 4+. Les perfs sont mauvaises de toute façon sur les anciennes versions et surtout il n'est pas possible de tout faire.

Je ne vais pas rentrer plus dans les détails de cette session assez technique, mais les slides sont dispo ici.

My Android is not an iPhone like any others

Concernant ma session, voici les slides (un article avait déjà été publié sur ce blog) :

Controlling Grundfos pumps with iOS and Android devices

Un mot sur la session de Adrian Kosmaczewski qui nous expliquait ce qu'ils ont mis au point pour piloter des pompes. Ils ont créé des connecteurs infra-rouges capable de dialoguer avec toutes sortes de pompes et pluggables sur des iPhones. Ils ont ensuite mis au point des applications permettant de récupérer des informations de la pompe et même de la piloter (accélérer, ralentir, augmenter le débit, ...). Tout cela pour le plus gros vendeur de pompes de la planète : Grundfos. Comme quoi il y a des applications pour tout !

Kenote de fin : What's next ?

Saul Mora a voulu nous parler de l'après mobile. Il a commencé par nous retracer l'historique de l'informatique depuis les mathématiques jusqu'au PC, en passant par la calculatrice de Leibniz, puis les ordinateurs portables et enfin les téléphones mobiles. Il nous a ensuite donné ses "prédictions". Même si le jeu est compliqué, il ne s'est pas trop mouillé :

• Des meilleures batteries, pour que nos nouveaux joujous durent plus d'une journée.
• Les wearables : montres (Gears), vêtements, chaussures (Nike), lunettes (Google Glasses), bracelets santés (Fitbit).
• Les interfaces non touchables, commandes vocales (Siri, Google Now)
• iBeacon ou équivalent
• Le Machine Learning (Google Now) et les réseaux de neuronnes articificiels (IA)
• Mesh Networking : analyse du trafic et communication entre véhicules pour les voitures autonomes

Tous ces éléments faisaient écho à la présentation de Donna le matin, où comment la science fiction rejoint aujourd'hui la réalité. Et de conclure que nous (les humains) devions aussi avoir notre place dans tout ça, que tout cela ne doit exister que pour améliorer l'humanité...