vendredi 12 octobre 2012

Pourquoi la réalisation d'une IHM est-elle complexe ? 1/2

Introduction


Mon projet professionnel s’est fondé, il y a plus de 15 ans, sur un constat fait lorsque j’étais élève ingénieur. En raison de mon intérêt pour les IHMs, je m’orientais en dernière année vers une spécialisation en Interface et Communication Homme Machine. Grace à cela, je suivais quelques cours sur les technologies de développement de la couche de présentation. Un nouveau cours, optionnel cependant, faisait ouvrir de gros yeux à tout l’amphi : l’ergonomie logicielle. Grace soit rendue au jeune professeur qui tentait, en territoire manifestement hostile, de distiller l’importance du facteur humain dans les projets informatiques ! Son constat était pourtant limpide : l’outil informatique finit toujours par interagir avec l’être humain et une bonne part des coûts de développement sont imputables aux aspects IHMs. Pourquoi diable aucune véritable méthode de conception d’IHM n’est-elle enseignée à ceux qui vont les implémenter ?

Avec le recul, la situation n’a pas tellement changée et je constate, sur de nombreux projets, à quel point l’aspect IHM est, soit sous-estimé, soit géré de façon très artisanale. Certains, encore trop nombreux, pensent que l’IHM est un problème secondaire, facilement sous traitable, et finalement indigne de faire partie du cursus d’un ingénieur ou même d’un technicien supérieur. Non, l’IHM n’est pas un aspect qui s’improvise ou qui se résume à laisser un graphiste passer un coup de peinture. L’IHM est un problème complexe, au cœur de la valeur d’un logiciel. Je vais tenter d’expliquer pourquoi dans ce billet…  

Une problématique à 3 dimensions




La première difficulté consiste à appréhender la problématique de l'IHM dans sa globalité, sans en oublier certains aspects.

Il y a trois facettes à adresser

La technologie : le côté Machine


Une IHM s'implémente, c'est à dire qu'elle se traduit in fine par des lignes de codes qui sont très dépendantes de la technologie utilisée (application web ou native, langage de développement, type de terminal à adresser).

Le codage de l'IHM représente une partie de code importante, souvent majoritaire dès lors que l'on souhaite avoir une expérience utilisateur avancée. D'une manière générale, plus les interactions sont complexes, plus les coûts de développements liés à l'IHM augmenteront. Souvent, on atteint des rapports 70/30, entre le code côté couche de présentation et celui côté serveur.

Il existe des exceptions notables, liées à la technologie utilisée. Il sera par exemple beaucoup plus simple de réaliser une IHM auto adaptative (responsive design) avec un développement Android natif que pour une application Web 1.0. De même, j'ai remarqué un saut de complexité, lorsqu'on passe d'IHMs orientées consultation vers des IHMs transactionnelles, c'est à dire avec une part de saisie importante. 

Concrètement, l'IHM est implémentée par un ou plusieurs développeurs, rarement spécialisé sur les technologies liées à la couche de présentation et généralement avec peu d'expérience. En effet, en France, le statut de développeur est peu valorisé, un développeur avec plus de 5 ans d'expérience étant fortement invité à faire autre chose. De même, si en pratique, le développeur est spécialisé dans une ou deux technologies (Ex : Java, .Net), il a très rarement connaissance des règles d'ergonomie, parce qu'il n'a pas été formé pour. Pire, la plupart du temps, cet aspect ne l'intéresse absolument pas et il voit l'implémentation IHM comme une partie ingrate de son travail, préférant s'intéresser aux aspects back-office de l'application. Bien évidemment, il existe des exceptions, mais j'ai rencontré très peu d'experts techniques sur la couche de présentation.    

L'argent étant le nerf de la guerre, minimiser le code de la couche de présentation est un enjeu de l'équipe de développement, et du chef de projet en particulier. L'aspect IHM étant un aspect mal maitrisé, l'équipe projet aura tendance à minimiser les risques, en simplifiant au maximum par rapport aux aspects techniques. C'est le fameux "on ne peut pas le faire", qui est avancé avec plus ou moins de bonne foi.

Côté relationnel, le développeur manifeste une tendance à la réserve, plus généralisée que dans d'autres métiers. Sa culture cartésienne, le conduit à poser le problème dans toute sa complexité avant d'avancer une solution qui doit traiter tous les cas possibles. Ceci explique la complexité des IHMs laissées aux seuls techniciens et conduit à une certaine résistance au changement, lorsque le besoin utilisateur évolue pendant le projet. Au final, on a souvent une équipe qui campe sur les spécifications fonctionnelles sans prendre d'initiative sur l'IHM. C'est dommage, car ce sont eux, qui, étant au plus prêt, sont le plus à même d'être force de proposition.
           

L'ergonomie : le côté Humain


De nombreux techniciens ont tendance à l'oublier, mais il y a un être humain derrière l'écran. Celui-ci fonctionne avec des codes très différents de la machine. Il est bien moins cartésien que le développeur qui a une formation scientifique. L’utilisateur ne voit l'application que par son IHM. Ce qui est le sommet de l'iceberg pour l'équipe de développement, représente l'essentiel pour l'utilisateur humain.

De même, l'utilisateur humain va raisonner en termes de service rendu par rapport à son activité alors que l'équipe de développement à un raisonnement orienté architecture, tournée vers les données. Plutôt que de se dire comment informatiser cette activité, le technicien a tendance à se demander comment présenter ces données. A cela, s'ajoute en milieu professionnel, le langage métier de l'utilisateur, peu compatible avec celui, très hermétique de l'informaticien. Tout concourt à un dialogue de sourd qui, de toute façon, n'a souvent jamais lieu !


Pourtant, concevoir une IHM, sans faire dialoguer ces deux mondes ne me semble pas concevable ! C'est précisément là que l'ergonome intervient, dans sa capacité à tenir compte à la fois des contraintes techniques, et de celles issues du facteur humain (physiologie, contexte d'utilisation, psychologie cognitive), pour produire une IHM réalisable. Dans un monde idéal, le choix du matériel et de la plateforme logicielle, résulterait d'une préconisation de l'ergonome par rapport à un contexte d'utilisation (Ex: pistolet à code barre pour une activité de ramassage). En réalité, le contexte hardware et software est souvent imposé : absence de budget pour financer du matériel, équipe de développement formée aux applications webs uniquement.

Bien souvent, l'ergonome sera le seul garant de la présence de l'utilisateur final dans le projet. On est ici à la frontière entre les sciences dures et les sciences humaines. Pour ma part, je pense que le traditionnel mépris des sciences dures envers les sciences humaines, n'est pas étranger à la difficulté de l'application de la démarche ergonomique dans les projets informatiques.

Contrairement au développeur dont on ne peut pas se passer, l'ergonome reste bien souvent en option sur les projets. C'est moins vrai dans les projets webs où l'ergonomie est immédiatement identifiée comme un enjeu majeur. Pour des applications internes, alors que les interactions sont souvent plus complexes et les fréquences d'usage plus importantes, l'ergonome est malheureusement rarement là. Quand il est présent, l'ergonome n'est pas toujours spécialisé sur le travail sur écran et intervient parfois trop tard dans le projet, comme caution ou bien comme pompier quand les utilisateurs râlent.


Le graphisme : le côté agréable à regarder


J'entends par graphisme tout ce qui concerne le rendu visuel des composants IHMs. Le terme de "skin" (peau en français) me semble la notion la plus proche : on peut changer de skin sans modifier le dialogue Homme/Machine. Techniquement parlant, il peut s'agir de feuilles de styles CSS pour une application Web ou d'un "look and feel" pour une application native.

Le graphisme nous fait entrer dans le monde de la subjectivité. Il y a une dimension artistique, dans la capacité du graphiste, à livrer des images, dont l'assemblage produira une impression positive ou négative. Quand on voit à quel point une application ayant quelques années parait vieillotte, on comprend qu'on entre dans le monde de la communication, avec des effets de modes, par définition cycliques.

Autant le couplage ergonomie/technologie est fort, autant le couplage du graphisme avec l'ergonomie et la technologie est plus faible. Attention, je ne dis pas qu'il est inexistant, mais il est me semble possible d'habiller ou de "rewamper" l'application en fin ou après son implémentation.

C'est parce que le graphisme est très souvent confondu avec l'ergonomie, que je refuse de produire des maquettes habillées graphiquement. Je n'en ai tout simplement pas le talent, sans oublier les biais induits en phase de maquettage : discussions sans fins sur les "gouts et les couleurs".

Pendant longtemps, j'ai tenu envers l'habillage graphique, le même discours que je reproche à certains techniciens envers l'ergonomie : un aspect secondaire. C'est une grave erreur, car l'impression véhiculée par l'application au premier coup d'œil (l'effet WAOUH) est essentielle. Chez un éditeur de logiciels, par exemple, c'est sur cela qu'un prospect se basera lorsqu'il établit une "short list" avant un achat. Tout simplement parce qu'il a très peu de temps pour évaluer les dizaines de logiciels sur le marché. La couverture fonctionnelle et la qualité de l'ergonomie, demandent un minimum de temps pour être évaluées. En généralisant, je pourrais également parler de la superficialité de notre société, où la forme est bien souvent privilégiée au fond...

La problématique IHM est pluridisciplinaire


On le voit, une approche exhaustive de la problématique IHM, amène à considérer ces trois aspects à la fois. Comme ils nécessitent des compétences très différentes, il faut a priori faire intervenir des personnes différentes : un graphiste, un ergonome, et au moins un développeur.



Mon retour d'expérience est que les projets où ces trois interlocuteurs sont effectivement représentés sont (très ?) minoritaires. Parfois, on a un graphiste mais pas d'ergonome : c'est l'application vitrine, très agréable à regarder mais pas forcément utile ni utilisable. Ce type d'application pullule en ce moment sur les plateformes mobiles (Exemple: voir cet article). Plus rarement, l'ergonome est présent mais le graphiste absent. Ces deux cas sont généralement la conséquence d'une confusion entre ergonomie et graphisme. Reste, le cas encore trop général : pas de graphiste ni d'ergonome. Soit il n'y a pas de maquette et la réalisation de l'IHMs est laissée au seul développeur, non formé pour, et qui fait ce qu'il peut. Soit une maquette est improvisée par un analyste et implémentée "au pixel près" par le développeur. Les cas d'improvisations complètes de l'IHM sont nombreux sur le terrain, y compris chez les grands comptes.

J'ai également pu constater un silotage des interventions, c'est à dire une absence d'interactions entre les différents acteurs. L'ergonome intervient quelques jours pour réaliser une maquette ou un audit en début de projet puis repart, laissant l'équipe technique démonter techniquement ses propositions. Idem pour le graphiste, qui propose des habillages graphiques avant même que l'équipe technique ne soit constituée. Plus généralement, les interlocuteurs IHM ne sont pas toujours du même côté dans le traditionnel conflit maitrise d'œuvre (équipe technique), maitrise d'ouvrage (graphiste et parfois ergonome).

Comment y remédier ?

La première solution sera la polyvalence. Mais les doubles, voir triples compétences, sont rares et souvent déconsidérées. Si l'on admet que le développeur soit en mesure d'implémenter sur tous les langages et sur n'importe quelle plateforme, un développeur s'intéressant à l'ergonomie sort de son domaine de compétence. Pourtant, n'y a-t-il pas davantage de cohérence s'il a choisit de se spécialiser sur la couche de présentation ?

La seconde solution consiste à faire parler tout ce petit monde, ce qui implique de les associer dans la même équipe projet. Des recouvrements sont possibles et même souhaitables. Les livrables du graphiste sont parfois fortement couplés à la technologie utilisée (Ex : nine patch sous Android). L'ergonome peut aussi moduler ses propositions en fonction des difficultés techniques de réalisation, allant vers le meilleur rapport ergonomie/coût. Les méthodes agiles me paraissent fournir le bon contexte pour mettre fin à ce silotage.

Conclusion


La problématique IHM est complexe car elle amène à faire collaborer des sensibilités très différentes. Trop souvent réduite à son aspect technique, il reste selon moi pas mal de chemin à faire sur le terrain et au niveau formation pour réellement mettre en œuvre des méthodes de conception faisant place à l’artiste et au facteur humain.

Dans un prochain billet, je me pencherais sous un autre aspect de cette complexité, à savoir le grand nombre d’inconnues d’une problématique IHM.

mercredi 20 juin 2012

Retour d’expérience d’un ergonome sur Android

Le projet voltaire est une application d’apprentissage d’orthographe disponible sur l’AppStore : http://itunes.apple.com/fr/app/orthographe-projet-voltaire et sur google play : https://play.google.com/store/apps/details?id=com.projet.voltaire.


A l’occasion de la réalisation de la couche de présentation de cette application sous Android, je vous propose de faire un retour d’expérience sur les possibilités de cet environnement, avec un œil orienté ergonomie bien sûr. Attention, car malgré ma longue expérience en développement d’IHM, je reste un newbie sur ce système. Ce qui suit n’est donc que le fruit d’une trentaine de jours de développement, intensifs malgré tout.

  L’environnement de développement


Pour l’habitué aux environnements Java, le démarrage sous Android se fait en toute simplicité : une installation de la dernière version d’Eclipse suivi de l’installation du SDK Android et enfin du plugin ADT pour Eclipse fournit un environnement de développement opérationnel.
La première réelle difficulté a été de choisir, parmi les 14 versions disponibles, quelle serait celle utilisée pour notre développement. On est parti sur une version 2.1, déjà très riche fonctionnellement, et apte à tourner sur plus de 80% des devices en France.
L’excellente qualité de la documentation en ligne et la profusion de tutoriaux sur la toile, m’ont permis de progresser rapidement. L’autoformation est tout à fait envisageable et j’évalue le temps de montée en compétence pour un bon programmeur JAVA client riche (GWT, ou Swing) entre 5 et 10j. L’analogie avec l’API Swing est assez saisissante (mécanique événementielle, couplage lâche assuré par des interfaces d’écoute, dessin des composants via une API de dessin 2D). Cependant, on a ici, quelque chose d’emblée beaucoup plus mature et qui ne souffre pas d’un historique à rallonge avec de multiples couches logicielles (Ex : AWT).

Les sources de l’API android ne sont proposées au téléchargement via le SDK Manager qu’à partir la version 4.0. C’est un petit peu plus complexe à télécharger pour les autres versions, mais je vous conseille vivement de configurer Eclipse sur ces sources pour pouvoir entrer en debug dans l’API. De même, un petit coup d’œil dans le répertoire d’installation du SDK android, vous permettra par exemple de voir comment sont organisées les ressources graphiques d’Android.

  L’émulateur

Le SDK embarque un émulateur permettant de faire tourner son application et de la débuguer en temps réel. Mon retour d’expérience est plutôt mitigé.
Il reproduit fidèlement le rendu du device mais trouve ses limites précisément sur l’expérience utilisateur : interactions tactiles difficilement simulables, le rendu pas en taille réelle ne permet d’évaluer les problématiques de lisibilité, rendu sur tablette non émulable en 2.1.
En outre, l’émulateur est bien trop lent à démarrer : environ 5 minutes entre 2 runs si l’émulateur n’est pas démarré, 2 à 3 minutes sinon. Cela dépend de la machine bien sûr, mais c’est beaucoup trop long quand, en phase d’industrialisation, on doit lancer de multiple fois pour intégrer les ressources graphiques faites par le designer.
Nous avons fait le choix de se procurer 3 devices : une Galaxy Tab 10" (catégorisé xlarge par Android), un galaxy Mini (catégorisé small par Android), une tablette Archos 7p (catégorisée large par Android). L’installation du device a été le plus souvent très facile : reconnu immédiatement ou pilote téléchargé automatiquement après branchement sur le port USB. L’Archos a nécessité une recherche et une installation manuelle du pilote USB ADB sur internet. Au final, le développement, device toujours branché, est devenu la règle, procurant une productivité de développement très très intéressante.
Je ne le répéterai jamais assez : l’expérience utilisateur est bien plus critique en situation de mobilité que sur desktop. Le projet Voltaire propose par exemple d’identifier une faute d’orthographe en pointant le, ou les mots en erreur. On s’est rendu compte, lorsque le mot était court (Ex : erreur d’accent sur le a) et que le device était petit, que le pointage devenait très difficile. Ce problème n’était pas détectable sur l’émulateur où le pointeur est simulé par un clic souris. On l’a résolu en mettant une tolérance sur les zones « touchables » et en testant sur le device le plus petit.   
Au final, je conseille de limiter l’usage de l’émulateur à la phase de test, où il permettra de tester le rendu sur des résolutions exotiques, ou sur des devices que l’on ne peut se procurer.

  Une grande richesse fonctionnelle pour l’IHM

La philosophie de la programmation Android, repose sur la dissociation entre les vues et les contrôleurs. Ce principe est depuis longtemps admis en conception objet (design pattern MVC) mais est interprété sous Android de la façon suivante : les vues (arborescences de composants et politiques de placement par rapport à leur conteneur) sont décrites de manière déclarative dans des fichiers xml, tandis que les contrôleurs sont décrits programmatiquement dans des classes JAVA. Cependant, afin de pallier aux limites du déclaratif (cas d’une IHM à l’arborescence dynamique), il reste possible de déclarer ou modifier  les vues programmatiquement directement au sein des contrôleurs. C’est très puissant et plutôt bien vu, mais attention à ce que l’exception ne devienne pas la règle : en limitant au maximum les manipulations programmatiques de la structure des vues, on favorise la maintenabilité et on maximise l’intérêt du GUI designer.

Les drawables

L’une des grandes forces d’Android est qu’il permet un controle très fin du design. Tout le dessin des widgets Android est réalisé via des ressources externalisées : ces drawables étant facilement surchargeables, il est très facile d'en customiser le rendu

Android s’affranchit du phénomène de réduction de la taille des images sur des écrans à forte densité, en proposant de livrer les ressources graphiques en plusieurs tailles (0.75x, 1x, 1.5x, 2x) dans des sous répertoires dédiés. C’est élégant, car sans aucun impact sur le code, mais cela alourdit le poids global de l’application qui sera installée avec l’ensemble des ressources graphiques. A quand une optimisation pour n’installer que les ressources adaptées au device ?.  
D’autre part, un drawable n’est pas seulement définissable directement sur une ressource graphique,  il est possible de définir un drawable via un fichier xml.
Les barres de progression du projet voltaire sont ainsi définies de manière déclarative, ce qui permet de skinner leur couleur sans avoir à faire appel au graphiste :

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android" >
    <item android:id="@android:id/background">
        <shape>
            <corners android:radius="5dip" />
            <gradient              
                android:angle="270"
                android:startColor="#FFFFFF"              
                android:endColor="@color/WoonozLightGray"
             />
        </shape>
    </item>
    <item android:id="@android:id/progress">
        <clip>
            <shape>
                <corners android:radius="5dip" />
                <gradient              
                            android:angle="270"
                            android:startColor="@color/WoonozLightGreen"              
                            android:endColor="@color/WoonozDarkGreen" 
                />                          
            </shape>
        </clip>
    </item>
</layer-list>

Les styles

Le rendu visuel des composants graphiques est largement paramétrable et la notion de style permet de mutualiser ce rendu afin de garantir une cohérence au design. C’est à double tranchant, car le bon sens ergonomique, voudrait qu’on utilise les styles par défaut, au nom de la cohérence avec les autres applications. C’est sur ces bases qu’Apple ferme son système, en ne facilitant pas la tâche pour skinner une application iOS (Ex : il est très difficile de changer la couleur d’une barre de progression).
Rien de tel sous Android qui permet de tout faire, même si des esprits chagrins regretteront que cela ne se fasse pas sur la base de CSS mais sur des fichiers xml à la structure propriétaire.
A l’usage, le design de l’application est piloté par trois fichiers :
·         Colors.xml : contient la palette de couleurs de l’application
·         Themes.xml : décrit les styles à appliquer pour chacun des composants graphiques 
·         Styles.xml : décrit le contenu de chacun des styles
L’ensemble du design étant externalisable, il devient très simple de définir plusieurs skins, sans intervention sur le code. C’est d’ailleurs l’une des limitations d’Android, on ne peut changer le style d’un composant dynamiquement après son instanciation (contrairement à ce que l’on fait couramment en web).
Si la notion de style intéressera essentiellement le designer, elle nous à permis ponctuellement d’assurer quelques règles ergonomiques 

Sur l’exemple ci-dessous, on force la taille minimale des boutons à 47x47, ce qui correspond précisément à la surface minimale pour qu’une zone soit touchable par un doigt humain.

<?xml version="1.0" encoding="utf-8"?>
<resources>

    <!-- Styles généraux -->
    <style name="WoonozButton" parent="@android:style/Widget.Button">
        <item name="android:textSize">12dp</item>
        <item name="android:gravity">center_vertical|center_horizontal</item>
        <item name="android:typeface">sans</item>
        <item name="android:textColor">@color/WoonozBlack</item>
        <item name="android:background">@drawable/woonoz_button</item>
        <item name="android:focusable">true</item>
        <item name="android:clickable">true</item>
        <item name="android:paddingLeft">15dp</item>
        <item name="android:paddingRight">15dp</item>
        <item name="android:paddingTop">10dp</item>
        <item name="android:paddingBottom">10dp</item>
         <item name="android:minWidth">47dp</item>
         <item name="android:minHeight">47dp</item>
    </style>
</resources>

Les 9 patch

),  Android permet d’exploiter les ressources graphiques sans déformation ni effet de pixellisation, quelle que soit la taille et la résolution de l’écran. Le travail du graphiste est considérablement réduit par la quasi absence de découpage des images (contrairement aux applications Web ou iOS par exmple). Enfin, en ne stockant en définitive que les pixels utiles, le poids global des ressources graphiques est considérablement réduit.
Le SDK fournit un outil permettant de transformer une image standard en un 9 patch. C’est un peu difficile à expliquer mais il s’agit de matérialiser par des pixels noirs dans le contour de l’image : les zones étirables d’une part, le sous rectangle réservé à l’affichage du contenu, d’autre part. A l’usage, j’ai trouvé l’outil un peu rudimentaire (le chemin du dernier fichier ouvert n’est pas sauvé, la pose des pixels sur des images de grande taille est fastidieuse), mais le concept est franchement plutôt génial.
Grace au 9 patch, une seule ressource (820 octets seulement), nous a permis d’afficher, sans effets disgracieux l’ensemble des boutons du projet Voltaire.

Cependant, les 9 patchs ne permettent pas de tout gérer : les photos et les images sans axe de symétrie ne sont pas toutes « 9 patchables ». Dans certains cas, les images ont du être retravaillées par le graphiste pour qu’on puisse placer des zones étirables.

Impossible d'étirer horizontalement


Ajout d'une bordure pour étirer horizontalement
Côté maintenance, on s’est demandé si la création des 9 patchs était à réaliser par le graphiste ou bien le développeur. Dans notre cas, c’est le développeur qui a maintenu les 9 patch. D’un côté, il pouvait visualiser le rendu directement dans l’application. D’un autre côté, à chaque relivraison d’une image par le graphiste, il a fallu redéfinir les patchs.  Egalement, comment s'assurer de la cohérence des patchs sur des ressources graphiques livrées en 4 ou 5 tailles ? Ceci ampute pas mal la capacité du développeur qui a autre chose à faire que de placer les patchs. Avec le recul, je pense que c’est un travail à réserver au graphiste, mais qu’il faut prévoir une formation spécifique.   

Gestion des différents types d’écrans

Contrairement à l’environnement iOS où la variabilité des tailles d’écrans et des résolutions est limitée par Apple (ce qui autorise une philosophie de placement des composants graphiques en absolu), la taille physique et la résolution de l’écran sont à considérer comme non déterminés, en raison du trop grand nombre de device.
En ergonomie logicielle, la taille physique et la résolution de l’écran, le rapport hauteur sur largeur, sont des éléments critiques pour organiser l’affichage. L’utilisateur doit avoir en permanence,  l’ensemble des informations utiles à la tâche en cours. Si, comme je le vois trop souvent sur des applications web, une partie des informations est cachée via des barres de défilement, l’expérience utilisateur est dégradée.
J’ai été très impressionné par ce que propose Android en la matière. Du classique d’abord, avec la possibilité de définir des politiques de placement (layouts) permettant de placer les sous vues en fonction de la position et de la taille de la vue parente. Cela permet de profiter de toute la surface d’affichage disponible et de privilégier les sous vues ergonomiquement plus importante en leur attribuant un poids plus important.

Plus originale est la possibilité d’avoir une vue spécifique en fonction du type d’écran (petit, normal, grand ou très grand), le tout sans écrire de code.  
Rendu pour smartphone

Rendu pour tablette

Quand on sait que cette mécanique s’applique aussi pour gérer le basculement entre les modes portrait et paysage, on comprend qu’Android fournit là un moyen de toujours adapter le contenu à la surface d’affichage réelle.
Le projet Voltaire tourne aussi bien sur des smartphone 2.7pouces (240x320) que sur des tablettes de plus de 10 pouces (1024x768). Sur les grands écrans, on profite de l’espace disponible pour afficher plus d’informations. Sur les petits écrans, il a fallu réduire les marges et les espacements entre composants pour ne pas perdre en lisibilité. Au final, on est arrivé à une optimisation ergonomique pour tout type d’écran, inimaginable pour une application web, le tout sans écrire de code (tout a été réalisé de manière déclarative). A bas les barres de défilement !

 Les animations

Android propose une API permettant de gérer les animations, à la fois très puissante et simple à mettre en œuvre.
  • C’est simple car le lancement se fait de manière asynchrone sans avoir à gérer de problématique multithread : il suffit de définir un modèle d’animation avec une durée, lorsqu’on l’applique sur une vue, android interpole les images automatiquement et joue l’animation de manière parfaitement fluide
  • C’est puissant car de nombreux types d’animations sont disponibles et qu’il est possible de surcharger le modèle pour des animations customisées (Ex : en modifiant le poids d’une vue dans son layout, on peut agrandir une partie d’un écran de manière animée en toute fluidité)
 Cette simplicité permet réellement de gérer de nombreux effets très intéressants, qu’il conviendra néanmoins d’utiliser avec parcimonie. Attention, en effet, à la pertinence ergonomique des animations, qui doivent chacune apporter une valeur ajoutée.
Pour le projet Voltaire, les animations nous ont permis de traiter les points suivants :
  • Design :
    • Les transitions entre écrans sont gérées avec un effet de défilement de pages de droite vers la gauche. Les animations de transition sont déclarées dans des fichers xml et mutualisées dans l’application grâce à la notion de style : pas une seule ligne de code
    • L’affichage du bandeau de réponse est géré avec un effet de translation combinée à un effet de fading permettant d’afficher le bandeau comme s’il surgissait de l’entête.
  • Ergonomie 
    • La problématique de lisibilité de la phrase sur petit écran a été résolue par un effet d’animation de type réduction : la phrase est affichée en gros caractères pendant la question (permettant un touché de la faute plus efficace) puis réduite pour permettre l’affichage de la règle



     Synthèse des problèmes rencontrés et des inconvénients


v      API
Ø      Impossible de passer un objet non Parceable entre deux écrans d’une même application
Ø      Problématique de mémoire suite à une reprise d’activité après libération de l’application (variables statiques non réinitialisées)
v      Technologie des 9 patch innovante, mais perfectible
Ø      Outil de création des 9 patch plutôt basique,
Ø      Problématique de cohérence des 9 patch en plusieurs résolutions,
Ø      Problématique de responsabilité sur la définition des 9 patch entre le développeur et le graphiste.
v      Trop grande souplesse de customisation ?
Ø      Conduit à un manque de cohérence des IHMs
v      Styles perfectibles
Ø      Les styles auraient gagné à s’appuyer sur les css comme JavaFX
Ø      Style non modifiable après instanciation du composant graphique
v      Design
Ø      Faible nombre de police
Ø      Impossible d’utiliser une police customisée de manière déclarative, uniquement de manière programmatique
v      Duplication des ressources
Ø      Fichiers de layout plus ou moins partiellement dupliqués lorsqu’on spécialise les layouts par type d’écran
Ø      Installation des ressources graphiques non optimisée : toutes les ressources sont systématiquement installées même si elles ne sont pas adaptées au device.
v      Déploiement
Ø      Démarrage pas entièrement gratuit
Ø      Déploiement multi version pas pratique

Conclusion

J’ai été assez bluffé par l’ergonomie de développement et par la qualité de la documentation. Certaines fonctions sont vraiment novatrices et l’ensemble est très bien intégré. Il faut bien reconnaitre, que j’ai pu, tout au long de mon expérience de programmation, me concentrer sur le fonctionnel de mon application, sans me disperser sur  des détails techniques.
J’ai également eu très peu de problématique de performance ou de mémoire, en tout cas pas plus que sur un développement pour desktop.

La richesse des fonctionnalités orientées vers le design et/ou l’ergonomie sont à mon avis, inégalées à ce jour. Ceci en fait un environnement très adapté à la réalisation d’applications à fort enjeu ergonomique. C'est pour moi le cas de toute application mobile à forte fréquence d’usage.
Par rapport à des applications webs, on retrouve la même liberté de design avec une productivité à mon avis très largement supérieure. La gestion du multi écran, très loin devant, et la simplicité de mise en œuvre des animations donnent une nouvelle longueur d’avance sur les applications webs.
Alors, Android, l’environnement de développement idéal pour réaliser des applications ergonomiques ?
Dans l’absolu, bien sur que non car la perfection n’est pas de ce monde. Paradoxalement, sa grande souplesse provoque un effet pervers très gênant : le manque de cohérence. En permettant de tout customiser, Android laisse la porte à la création de nouveaux composants graphiques, inconnus de l’utilisateur ainsi qu’à des écrans dont le look et la philosophie d’utilisation n’a rien à voir avec les applications standards Android. Les applications installées sur un device Android, ne se ressemblent pas et tendent à avoir une philosophie d’utilisation propre. Ceci se fait au dépend de l’utilisateur, qui ne peut s’appuyer sur des principes d’utilisation déjà connus, lors de la découverte d’une nouvelle application. 
Si un guide d’ergonomie est bien sur les rails, n’arrive-t-il pas trop tard et sera-t-il suffisant ? La certification serrée par Apple des applications publiées sur l’appStore, n’est à mon avis pas étrangère à la qualité de l’expérience utilisateur sur iOS et Google ferait bien de s’en inspirer.



vendredi 8 juin 2012

L'avis d'un ergonome sur le débat applications mobiles : web ou natif ?

Introduction


Les applications mobiles ont le vent en poupe. Chaque société veut mettre à disposition son site mobile, question d'image. Ca me rappelle les années 2000 avec la frénésie du web. Là encore, il faut bien disjoindre les applications vitrines destinées à donner une image commerciale de modernité et les véritables applications mobiles prenant en compte l'itinérance de l'utilisateur.
Comme pour les applications classiques, je suis souvent confronté au dilemme sur l'approche à tenir : application web ou application native. Ce choix est devenu est véritable débat, la plupart du temps alimenté par les seuls techniciens. En tant qu'ergonome, je me lance pour parler sous l'angle de l'utilisateur final.  En tant que technicien, c'est le retour d'expérience d'un vieux briscard de l'implémentation d'IHM.

Origine du débat


La montée en puissance des smartphone et des tablettes pose des problèmes majeures aux DSI. En effet, la profusion de device s'accompagne d'une pléthore de système d'exploitation, chacun proposant son ergonomie et son environnement de développement associé (android SDK/Java, Xcode/Objective C...). Les problématiques évoquées le plus souvent sont les suivantes : 
  • Comment adresser l'ensemble des plateformes sans exploser les coûts de développement ?
  • Comment vais-je trouver des développeurs compétents dans toutes ces technologies ?
  • Comment maintenir sur le long terme si le code est redondé sur chacune des plateformes ? 
La réponse est pourtant simple, HTML5 sachant par définition tout faire, je vais résoudre mes problèmes en faisant une application Web : 
  • Le code de la couche de présentation étant factorisé, je ne maintiens qu'une seule base de code
  • Je n'ai plus besoin de compétences spécifiques, des développeurs Web, plus faciles à trouver et donc moins chers, suffisent. 
  • Toutes les plateformes supportant HTML5, je ne gère plus qu’un seul environnement de développement
Sur le papier, la démonstration est imparable et la solution séduisante. Les arguments sont en effet recevables mais doivent être relativisés :
  • Les applications webs font elles aussi cohabiter plusieurs langages (CSS, Javascript, html, framework  web) : un bon développeur Javascript n'est pas aussi facile que cela à trouver 
  • A l'usage, il peut subsister du code spécifique en fonction du navigateur. Ne déplace-t-on pas le problème, avec une application multi plateforme, certes, mais pas multi navigateurs ?
  •  Il n'y a pas tant de code que cela pour la programmation des UI mobiles, ces applications sont souvent très simples. Au delà de 10 écrans, on peut s'interroger sur leur pertinence ergonomique. Rappelons que Apple recommande des applications mono fonctionnelles.
  • En terme de part de marché, adresser 2 voir 3 plateformes semble suffisant. Aux USA, Android et IOS occupe 80% du marché. Etant donné la fragmentation de la part de marché restante, quel est l'intérêt économique d'adresser des plateformes supplémentaires ? 

Les considérations techniques


Je n'ai pas connaissance d'autres arguments en faveur du développement web mobile. Voyons maintenant la réalité d'un point de vue technique. On a deux types d'approches pour le web mobile :
  • Site web mobile : application web classique dont le rendu est adaptée à la taille réduite de l'écran
  • Solution hybride (type phoneGap ou Titanium) : utilisation d'un framework faisant tourner une vue web dans une application native, ce qui permet de déployer l'application sur le market (App Store, Google play…) et de lever certaines limitations techniques (Ex : accès à la plupart des capteurs du device). 
Dans les deux cas, on peut chercher à approcher le rendu natif : cette approche type "canada dry", fait dire aux partisans des applications webs que ces applications n'ont rien à envier aux applications natives. Les applications natives seraient-elles donc promises à une mort certaine ?

Pas si sûr, car, en introduisant une couche d'abstraction supplémentaire, les solutions hybrides posent les problèmes suivants :
  • Effet boite noire de la couche d'abstraction : difficultés à customiser le rendu visuel du code natif généré.
  • Risque de régression accrue sur un code factorisé entre plate forme : une correction pour une plate forme risque de déstabiliser les autres.
  • Le natif a toujours un coup d'avance sur le framework : le décalage fonctionnel est inévitable entre la couche d'abstraction et la dernière version de l'API graphique (Ex: les nouveaux composants Android 4.0 sont-ils supportés ?).
  • La couche intermédiaire a fatalement un effet négatif sur les performances et donc la réactivité de l'IHM, qui sera indexé aux performances du navigateur pour le rendu HTML et l'exécution de code javascript.
D'autre part, et c’est un élément souvent ignoré, la productivité des solutions natives est très bonne grâce à une excellente ergonomie de développement :
  • Debugage en temps réel sur le device permettant d’identifier rapidement tout problème, y compris ceux liés à l’interface tactile)
  • Temps de cycle entre correction dans le code et visualisation du résultat sur le device au plus court (de 1 à 3 mn sur Android)
Ceci est à mettre en perspective avec la productivité des applications Webs qui est loin d'être démontrée. Certains problèmes (liés au comportement de l’IHM) ne se produisant que sur un device, sont très difficilement identifiables, conduisant à des séances de débogage « dans le noir », avec une démarche de type essai/erreur. Or comme, il faut parfois plus de dix minutes entre l’essai et le résultat sur le device (temps de compilation et de déploiement), on peut passer des jours à corriger des bugs d’affichage.
Hormis la courbe d'apprentissage initiale et la réticence aux changements des développeurs habituées à la programmation web, je doute du retour sur investissement concernant les coûts de développement. Au-delà de 20% de code spécifique, on perd l’intérêt de la factorisation. En dessous de 3 plateformes à adresser, les gains liés à la factorisation sont contrebalancés par une perte de productivité. Ainsi, si l'on adresse uniquement les 2 plateformes se taillant la part du lion sur le marché, on est à mon avis en dessous des coûts d'une solution unique web.

La maturité


Le développement natif permet l'accès à toutes les ressources matérielles et logiciels du device, de façon mature :
  • Accès aux capteurs (GPS, accéléromètre....)
  • Accès aux données du téléphone
  • Accès aux autres applications (Agenda, Contacts....)
Si cela n’est pas impossible en Web, c’est à la fois plus difficile et moins mature. En outre,  le support de HTML5 sur navigateur mobile demeure problématique et l’on se retrouve avec une situation similaire avec celles des navigateurs desktop du milieu des années 2000 ;
  • Support inégal de HTML 5 entre les navigateurs mobiles : le pire étant celui d'Android, (véritable Internet Explorer de la mobilité)
  • Risque de code spécifique en fonction du navigateur
  • Même les solutions hybrides ne parviennent pas à se connecter aux autres logiciels du système (agenda, contacts..).

Les considérations ergonomiques


Comme pour les applications web classiques, le choix web conduit, selon moi, à une expérience utilisateur dégradée
  •  Le choix des composants graphiques limité à ce qui fonctionne partout : notion de plus petit dénominateur commun ergonomique
  •  Gestion approximative de la taille des écrans : la difficulté à réaliser une application web plein écran (sans barre de défilement), fait tellement exploser les coûts qu'on en arrive à faire des IHMs en taille fixe, soit trop grandes (sur les petits écrans), soit trop petites (sur les gros écrans)
  • Gestion approximative des interactions tactiles : l'ergonomie web n'est pas conçue pour le tactile, les gestures sont à recoder en HTML5 (avec le risque d'incohérence avec le gesture natif).
  • On peut se poser la question sur la prise en charge d'autres fonctionnalités en web : basculement portrait/paysage, retaillage des ressources graphiques sans effets d'étirement (type nine patch en Android)...
  • Le surcout des améliorations ergonomiques est tellement élevé (Ex : faire une IHM web redimensionnable sur plusieurs navigateurs), qu'au mieux il compromet gravement les gains sur les coûts de développement. Plus souvent, il conduit à faire de graves concessions sur l'ergonomie (Ex : IHM en taille fixe)  
L'ergonomie des applications dépend de la plate forme
  • Les variations entre plateforme dépassent le simple rendu visuel des composants graphiques (skin)
  • Les composants graphiques ne sont pas les mêmes entre plateforme (Ex : equivalent du splitView iOS en android, équivalent des tile Windows Phone)
  • L'imitation du rendu natif en web est une mauvaise pratique : on perd la factorisation si on reproduit l'ergonomie de chaque plateforme, on pénalise les utilisateurs des autres plateformes si on choisit l'une des ergonomies.
  • A moins d'enfreindre la règle de cohérence avec le système d'exploitation, la seule ergonomie possible est une ergonomie web dont les normes semblent très mal connues en situation de mobilité.

Conclusion


D'un point de vue technique, le développement Web est loin d'avoir démontré sa productivité. A niveau de compétence égal, il est à mon avis au moins deux fois moins productif qu’un développement natif pour une expérience utilisateur très inférieure. La réduction des coûts de développement est un leurre : ce qu'on gagne en factorisation on le perd en tests et en code spécifique pour gérer les différences entre navigateurs et maintenir une ergonomie acceptable.
Plus grave, à mes yeux d'ergonome, le choix du web conduit selon moi, immanquablement à une expérience utilisateur dégradée. Ainsi, choisir l'application web revient à arbitrer en faveur de la technique au détriment de l’utilisateur. C’est à mon sens, ce qui s’est passé avec la venue des applications web dans les années 2000, avec un recul ergonomique des applications webs par rapport à leurs ancêtres en client/serveur, certes plus difficiles à déployer, mais tellement plus adaptées. Cependant, les exigences ergonomiques des applications mobiles sont bien plus importantes : l’utilisation en situation de mobilité impose une ergonomie optimisée, la taille des écrans et les nouveaux modes d’interactions changent la donne, les utilisateurs mobiles sont également très exigeants. Bref, ceci ne me semble pas compatible avec les contraintes des applications webs.

Le choix de l'application web peut néanmoins se justifier pour des équipes expérimentées en html/css/javascript et pour des applications à forte diffusion, sous réserve d'une utilisation occasionnelle avec peu de saisie (applications orientées document et non interactions). Pour les autres, la solution me semble évidente. Le développement en natif offre une meilleure flexibilité pour s'adapter aux fluctuations du marché : au lieu d'adresser d'emblée toutes les plateformes, on commence par la plateforme avec le plus de part de marché. N’est-ce pas une manière de ne pas se complexifier inutilement le problème ?

Ce type de débat, illustre selon moi, d’une part, l’approche techno centrée des architectes logiciels (qui ont souvent un angle mort sur les aspects IHM), et d’autre part, la vision strictement comptable des chefs de projets. Tout est résumé dans la phrase de Phil Libin (CEO d’Evernote) :  

« We could probably save 70% of our development budget by switching to a single, cross-platform client, but we would probably lose 80% of our users. ».

Ainsi, si ces débats sont sains, il ne faudrait pas qu’ils cachent d’autres problématiques, tout aussi importantes, lorsqu’on aborde un projet mobile :
  • Comment adapter mon application à une utilisation en mouvement ?
  • Comment adapter mon application à l'interaction tactile ?
  • Comment adapter mon application à un écran si petit ?
  • Comment mon application va-t-elle exploiter les fonctionnalités spécifiques à la mobilité (géo localisation, appareil photo...) ?