Cloud et ergonomie

L'idée de ce billet m'est venu après avoir constaté combien mon ressenti sur l'informatique dans les nuages avait pu évoluer depuis que j'ai découvert le terme magique "Cloud" il y a environ 2 ans. Encore une pseudo révolution qui va enchanter les commerciaux et les directeurs informatiques, friands d'acronymes et de nouveautés renversantes, me suis-je dit. Car, enfin, n'essaie-t-on pas de faire du neuf avec du vieux ? Après tout, il y a bien longtemps que nos données sont sauvegardées sur un serveur !

J'ai mis longtemps à percevoir comment cela allait impacter en profondeur l'usage des applications informatiques. A l'occasion de la sortie de la version Cloud du projet Voltaire où j'ai modestement participé à la conception du client Android, voici venu le temps de présenter en quoi, le Cloud permet de faciliter l'utilisation de nos applications, devenant un véritable levier ergonomique.

Aux origines

Remontons d'abord aux origines de l'informatique, à savoir une unité centrale non connectée au réseau. Poursuivre son travail sur une autre machine relevait de l'exploit, tant les obstacles étaient nombreux. Le seul moyen de faire transiter des données consistait à les copier sur un support physique magnétique dont l'espace de stockage était bien sur limité (ah les disquettes 1,2Mo !). On pouvait par exemple emmener son fichier Word au travail, à condition que l'OS de la machine du bureau et la version d'Office soient compatibles. Bien sur, en cas de modification du fichier, il ne fallait pas oublier de faire l'opération inverse pour récupérer ses modifications à la maison.

Ces difficultés ont conduit à un usage en silo des outils informatiques. Chaque ordinateur est utilisé en vase clôt, l'ensemble des données reste en local. S'il est déjà possible de suivre ses comptes informatiquement, il y a de puissants freins ergonomiques. Il faut ressaisir manuellement les relevés de comptes papiers et la plupart des situations où je pourrais avoir besoin de l'état de mes comptes ne sont pas compatibles avec les contraintes suivantes : être à proximité de l'ordinateur, avoir le temps nécessaire (à l'époque plusieurs minutes pour démarrer, lancer le logiciel de gestion personnel et accéder à l'écran voulu).

L'avènement des réseaux, d'internet et des applications Web

Avec la possibilité de relier les machines entre elles, le partage d'informations est devenu beaucoup plus simple. En stockant une base de données sur une machine dédiée, les applications clients/serveur permettent, dans les années 90, à plusieurs utilisateurs de travailler en même temps. Il devient également possible, sous réserve que l'application cliente soit installée sur chacun des postes, de travailler sur plusieurs machines. Cela reste théorique car la machine est très liée à son utilisateur pour diverses raisons : OS pas encore multi utilisateur, caractère très privatif de l'ordinateur à l'époque. De plus, cela reste cantonné au milieu professionnel, hormis quelques geeks qui se montent un réseau filaire privatif à la maison !
Avec la démocratisation d'internet au début des années 2000, les barrières technologiques entre l'informatique du bureau et celui de la maison sautent ! N'importe quelle machine est désormais capable de lire et d'écrire des données sur une machine distante, pas forcement clairement identifiée.
Parallèlement, Internet brise les frontières entre les OS, en permettant d'afficher des informations sous un format compris par toute les machines : le HTML. Les applications Webs permettent une utilisation depuis n'importe quelle machine, sans contraintes (pas d'installation préalable) mais au prix d'une expérience utilisateur dégradée (HTML étant orienté vers des interactions liées à la consultation de documents).

Vers une utilisation distribuée sur plusieurs terminaux

Techniquement, le Cloud est donc né il y a plus de dix ans ! A ce moment, l'utilisateur était plutôt réticent à envisager de partager ses données personnelles ou même de les stocker à distance. Avec l'avènement des réseaux sociaux, les verrous sautent, au grand bonheur de grosses sociétés dont le modèle économique est basé sur l'exploitation des données personnelles. Voir, en la mise à disposition gratuite d'espace de stockage toujours plus important, un appât pour capter les données des utilisateurs, n'effraie que les plus vieux d'entre nous. Le Cloud a de beaux jours devant lui car la nouvelle génération ne craint plus de confier ses données à un tiers.

Mais le Cloud n'est pas que cela et c'est là que cela devient intéressant pour l'ergonome que je suis. Avec la multiplication des terminaux connectés à Internet et leur démocratisation, les populations et les situations d'usages se sont considérablement élargies. A brève échéance, la quasi totalité de la population des pays développés sera multi équipées de terminaux internet : smartphone, tablette, ordinateurs bureautiques, consoles de jeux... Chaque terminal correspond à une situation d'usage particulière : fixe (l'ordinateur classique au bureau), mobile (le smartphone qui tient dans la poche et que j'emmène partout), semi mobile (la tablette transportable dans les différentes pièces de la maison).

Exemple de la dropBox

Client iOS

Client Android

L'exemple même d'une application basique fonctionnellement, qui fonde sa valeur sur son aboutissement ergonomique. Il s'agit d'un simple gestionnaire de fichiers dans les nuages, mais dont l'IHM est disponible sur la plupart des plateformes : web, bureautiques (Windows, MacOS...) et mobiles (iOS, Android...).

Après avoir créé un compte sur l'application Web, l'utilisateur installe un module client sur chacun des terminaux qu'ils possèdent (Ex : un mac, un PC, un smartphone) et couple sa dropbox à son device. Dès qu'un terminal couplé est connecté à internet, les données sont synchronisées automatiquement et silencieusement. Ainsi, toute mise à jour, ajout, suppression d'un fichier, se reflétera sur l'ensemble des terminaux couplés, sans intervention de l'utilisateur. En couplant de stockage des photos d’un smartphone à un répertoire synchronisé, on a ainsi la surprise de voir les photos arriver au fil de l’eau sur chacun des appareils du réseau wifi domestique !

Cette réplication automatique et transparente, permet d’enchaîner des sessions d'utilisation sur des terminaux aussi différents qu'une tablette, un smartphone, le PC personnel fixe ou portable ou bien le PC en libre service du restaurant du coin ! A l'utilisation, on s’aperçoit que les documents sont plutôt créés sur un ordinateur bureautique mais visualisés sur un autre device (tablette, smartphone...). 

Il y a peu de risque de perte, car les données sont répliquées plusieurs fois : sur les serveurs distants, mais aussi en local sur les postes clients. De plus, il est possible de revenir à des versions antérieures ou de récupérer un fichier supprimé. Enfin, il est possible de partager très simplement des fichiers via la génération d'un lien vers un fichier ou un dossier placé dans un espace de stockage public.

Grace à cette réplication, l'utilisation reste possible en l'absence de connexion, à l'inverse d'une  application web. C'est très utile en situation de mobilité où l'accès au réseau est intermittent. Astucieusement, l'espace de stockage étant encore limité sur les smartphones, l’utilisateur peut contrôler quels sont les fichiers répliqués, via un système de favoris.

La version Web

Car c'est bien le côté ergonomique qui distingue le système d'autres gestionnaires de fichiers en ligne.  D'une part, un client natif à été développé pour chacune des plateformes avec une ergonomie aussi léchée que possible. L'application web, bien qu'aboutie, apparaît comme un client secondaire, que  l'on consent à utiliser quand on a aucun terminal privé sous la main ! Cela démontre selon moi, l'intérêt d'adapter l'expérience utilisateur au terminal de visualisation plutôt que de concevoir une IHM multicontexte.

L'autre grande force de cette application repose sur la gestion d’un maximum de fichiers. Un maximum de type de fichiers est pris en charges (images, vidéos, fichiers aux formats office...) et sur l'ensemble des plateformes. De plus, l'ergonomie de visualisation est optimisée (diaporama et aperçu pour les photos, affichage très fidèle des documents Office).    

Exemple du projet Voltaire Cloud

Version en ligne

Le projet Voltaire est une application d’apprentissage de l’orthographe. La version en ligne, permet de tester son niveau afin d’établir un programme d’apprentissage très ludique et adapté à ses difficultés. Récemment, des versions natives iOS et Android sont sorties et connaissent un gros succès, grâce à une bonne expérience utilisateur et parce que l’apprentissage devient possible en situation mobile, même en l’absence de connexion internet.

Client Android

Cependant, l’utilisation conjointe des versions mobiles et de la version en ligne, n’avait aucun intérêt puisque les apprentissages n’étaient pas partagés. Bien évidemment, une première solution aurait été d’adapter la version web à un terminal mobile, mais cela n’aurait pas permis une utilisation hors connexion.  D’où l’idée de créer une version Cloud en adaptant les versions natives via un moteur permettant de synchroniser les apprentissages. Pour permettre une utilisation offline, les échanges avec le serveur sont réduits au strict minimum, le moteur d’apprentissage et les contenus sont embarqués côté client.

L’utilisateur peut ainsi démarrer son apprentissage en classe sur la version en ligne et le poursuivre sur son smartphone sur le chemin du retour, hors connexion. D’autres scénarios sont possibles mais illustrent tous comment le Cloud permet la continuité d’usage. Grace à la démocratisation des smartphones et grâce à ce logiciel, la fonction d’apprentissage est accessible en toute circonstance tout en offrant un confort d’utilisation adapté à la situation d’usage.  

Conclusion

Il y a clairement deux visions du Cloud : une vision technique, côté serveur, orientée vers les architectures de stockage distribuées et les moteurs de synchronisations et une vision ergonomique, côté client, orientée vers la multiplication des contextes d’utilisations et des terminaux de visualisations. 

J’ai essayé de montrer, à travers quelques exemples, comment les applications Cloud révolutionnent à mon sens le rapport à l’outil informatique en permettant la continuité d’usage. Ce concept me semble très important car il traduit le besoin grandissant d’avoir accès à des fonctionnalités, en tout lieu, à tout instant et dans toutes les situations. Pour autant, en fonction du contexte, l’utilisateur choisira toujours le terminal offrant la meilleure expérience utilisateur.

Tout comme il est impossible de concevoir un poste de conduite adapté à 100% des automobilistes, il est illusoire, de concevoir une seule IHM adaptée à une multitude de terminaux de visualisation et avec des modes d’interactions tout à fait différents. Si le Cloud aboutit donc à une architecture serveur distribuée et plus forcement centralisée, il conduit également à plusieurs modules dédiés à la présentation. Je parie à l’avenir sur plusieurs IHMs potentiellement utilisées par le même utilisateur, dans des technologies différentes mais avec des besoins fonctionnels strictement identiques. De quoi redonner ses lettres de noblesse aux architectures n tiers !

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.

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

Grace au nine patch (voir ce très bon tutoriel : http://www.ace-art.fr/wordpress/2010/10/14/tutoriel-android-partie-12-le-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.