L’ergonomie : combien ça rapporte ?

Pour gagner une affaire, un freelance est souvent amené à démontrer la rentabilité de ses interventions. Après 3 ans passés comme consultant ergonome indépendant, je suis ainsi régulièrement confronté à la problématique du retour sur investissement de la démarche ergonomique. Comment garantir que l'ergonomie conduise à des économies et non à des coûts supplémentaires ? 

Après 15 ans de pratique de l'ergonomie dans les projets informatiques, voici donc l'occasion de me risquer à un retour d'expérience. D’un point de vue comptable, les choses sont simples et se résument à calculer l’écart entre les coûts de l’intervention de l’ergonome et les gains qui en résultent.

Le coût d'une intervention ergonomique

Dans une étude de J. Nielsen actualisée en 2008, les coûts liés à l’ergonomie comptent pour 8 à 13% dans le budget d’un projet informatique. Nielsen recommande ainsi d’investir entre 10% et 20%, voire plus dans les années à venir…

Pour un projet de 500 k€ (Ex : projet de refonte d’une application web de 18 mois avec 3 développeurs et un chef de projet), cela revient à consacrer plus de 50k€ à l’ergonomie !  De quoi effrayer certains DSI, un tant soit peu sceptique des apports de la démarche. En outre, cela conduit à mon sens, à exclure  l’ergonomie des projets petits ou moyens, à destination des PME par exemple.

L’un des objectifs de mon projet professionnel étant précisément de démocratiser l’ergonomie logicielle, j’ai été amené à raisonner de manière plus pragmatique en cherchant à minimiser le coût de mes interventions.

Cependant, loin de moi l’idée de proposer une ergonomie au rabais, il s’agit au contraire de concentrer ses efforts sur les fondamentaux :

- L'analyse de contexte : l’analyse des usages, la modélisation de l'activité, le contexte logiciel et matériel, l’identification des types d'utilisateurs restent le socle de toutes les recommandations ergonomiques.

- L'assistance à la conception d'IHM : cycle de maquettage avec les utilisateurs finaux sur la base de 2 à 4 scénarios critiques, un groupe d’utilisateur de 3 à 6 personnes par scénario, 2 à 3 itérations (séance de 2h) étant nécessaires pour faire converger la maquette

- L'assurance qualité ergonomique : réalisation d’au moins 2 audits (analyse experte fait par l’ergonome) pendant la phase de développement, au moins un test utilisateur avant la mise en production.

Ceci m’amène au calcul de charges suivant :

* Les coûts sont calculés sur la base des hypothèses suivantes : TJM ergonome à 750€/j, coût journalier d’un salarié à 156€/j (salaire net médian à 1712€/mois)

Avec un coût moyen d’environ 20k€, on est loin des 50k€ issu du ratio de Nielsen. Dans mes expériences, je n’ai pas constaté de lien entre le budget total du projet et les coûts liés à l’intervention ergonomique. La corrélation est plutôt à faire avec le périmètre des fonctionnalités à implémenter, les fréquences d’usages, la variabilité des utilisateurs et des situations d’usage.

C’est pourquoi je propose à mes clients que l’analyse de contexte soit faite dans une prestation dédiée. Ce qui permet de proposer un plan d’action ergonomique personnalisé et chiffrable pour l’ensemble du projet.

En outre, il conviendrait, pour être exhaustif, d'ajouter les coûts de développement induits par les recommandations de l'ergonome. En effet, l'erreur fréquente de l'ergonome débutant est de proposer des évolutions difficiles à mettre en œuvre techniquement.

Ainsi, pour parvenir à rendre l’ergonomie accessible aux petits et moyens projets, il faut non seulement savoir renoncer à certaines techniques trop coûteuses (Ex : eye tracking, tests utilisateurs en laboratoire) mais aussi proposer des recommandations au meilleur rapport qualité ergonomique/coût de développement.

Quantifier les gains d’un accompagnement ergonomique

Là encore, si l’on en croit la littérature, les gains seraient phénoménaux, certains parlent de 10 à 100€ d’économisés pour 1€ investi !

Effectivement, en tant que développeur, j’ai constaté que les coûts de réalisation d’une évolution explosaient en fonction de l’état d’avancement du projet :

-          En phase de maquettage (base 1) : le plus simple à réaliser et à faire évoluer car il n'y a pas de code.

-          En phase de développement (x10) : à ce stade, le besoin doit être solidement étayé car cela risque de faire dériver le planning du projet

-          Après la mise en production (x100) : à ce stade, l’évolution est souvent abandonnée par manque de budget

Parce qu’il est en contact direct avec les utilisateurs finaux, un ergonome identifiera probablement quelques fonctionnalités ou évolutions très profitables, mais promettre un tel retour sur investissement me semble un peu présomptueux.  S’agissant d’estimer les gains, je préfère adopter une vision plus pessimiste, en raisonnant sur des objectifs à minima : 

-          Gains de productivité (>25%) :

o       Réduction des temps de saisie : optimisation des interactions, mise en place d'aides à la saisie

o       Réduction des erreurs de saisie : prévention des erreurs, contrôle des données au plus tôt

-          Gains lien à la formation (>25%)

o       Réduction des appels au support : moins d'appels relatifs à des difficultés d'utilisation

o       Réduction du temps de formation : une application ergonomique nécessite moins d’apprentissage

-          Réduction des coûts de développement de l'IHM (>33%)

o       Non développement de fonctions inutiles : soit parce qu'elles ne sont pas adaptées aux situations d'usage, soit en raison d’une faible fréquence d'utilisation, soit parce que trop peu d'utilisateurs sont concernés

o       Factorisation du code de l'IHM induite par le critère de cohérence : des écrans moins nombreux et qui se ressemblent sont plus faciles à coder.

-          Augmentation des ventes (>25%) :

o       Réduction du risque d'abandon de tâche pour les fonctions de paiement en ligne

o       Augmentation du taux de conversion

Parfois, les gains seront très nettement supérieurs aux valeurs planchers annoncées. J'ai en tête une boite de dialogue permettant de trouver le contrat d'un assuré dont on a optimisé l'utilisation, grâce à la mise en place de raccourcis clavier. En réduisant par 5 le temps moyen de la tâche de recherche d'un contrat (tâche effectuée en moyenne 100 fois/jour), on a fait bondir la productivité des utilisateurs de plus de 150% !

« Il faut proportionner l’effort ergonomique

en fonction des fréquence d’usage »

Le premier problème est que certains de ces gains ne se manifesteront que sur le moyen ou le long terme. Si les gains relatifs aux coûts de développement et à la formation correspondent bien à des postes du projet informatique, il est plus difficile d'intégrer les autres gains dans le calcul du ROI. La démarche ergonomique devient alors assimilable à un investissement que l'on amortira après la mise en production du logiciel.

Le deuxième problème est que certains gains sont qualitatifs :

-          Satisfaction utilisateur : on peut évaluer un niveau de satisfaction mais combien rapporte le fait d'avoir des utilisateurs contents ?

-          Amélioration en terme d'image pour le maître d’œuvre

Enfin, on ne fait le projet qu'une seule fois. On ne pourra jamais faire le différentiel avec ce qui se serait passé sans accompagnement ergonomique…

« Les gains de l’ergonomie sont infiniment

plus difficiles à évaluer que les coûts »

 

Les risques d'un ROI négatif

On ne peut exclure un échec de l'accompagnement ergonomique se traduisant par un ROI négatif. Selon mon expérience, il résulte alors d'une mauvaise gestion d'un ou plusieurs risques :

• Intervention trop tardive : l'ergonome est appelé en fin de projet alors que les marges budgétaires sont étroites, la mise en œuvre de ses recommandations nécessite une refonte majeure de l'IHM dont le coût est prohibitif.

• L'ergonome au début seulement : l'ergonome propose une maquette puis quitte le projet, ses recommandations sont déconstruites par l'équipe de développement pour des raisons techniques, l'IHM finale n'a que très peu à voir avec ce qu'il avait initialement proposé.

• Manque de réalisme des recommandations : l'ergonome propose des choses fabuleuses sur le papier mais qui s'avèrent très complexes à implémenter ou incompatibles avec la boite à outils de développement. Faut-il également rappeler que les contextes matériels et logiciels sont la plupart du temps figés avant même le démarrage du projet ?

• Surdimensionnement de l'accompagnement : dans sa volonté de bien faire, l'ergonome propose des techniques d'analyse trop coûteuses par rapport au budget du projet. Les gains sont réels mais le ROI devient négatif en raison des coûts.

Conclusion

Les optimistes diront que le ROI de la démarche ergonomique se situe entre 10 et 100 fois la somme investie. Les pessimistes diront qu'il n'est pas garanti et qu'on peut perdre la somme investie, soit jusqu'à 10% du budget du projet ! 

Pour ma part, je ne chercherai pas à cacher la complexité à évaluer un ROI par une formule toute faite. L'ergonome n'est pas un magicien, le ROI de son intervention est conditionné par :

• Sa capacité à proposer une intervention correctement dimensionnée : on peut prétendre à des gains importants même avec un accompagnement de 20j.

• Sa capacité à intervenir tout au long du projet : l'ergonome doit intervenir non seulement très tôt mais il doit défendre et faire évoluer ses recommandations pendant la phase de réalisation.

• Le contexte du projet : il est par exemple difficile d'obtenir des résultats lorsque l'équipe projet est réfractaire à la démarche ergonomique ou lorsque l'accès aux utilisateurs est impossible, certaines fonctionnalités peuvent également s'avérer inconciliables avec les situations d'usage...

Ainsi, ma première préoccupation avant de faire une proposition commerciale, consiste à m'assurer que le ROI de mon intervention sera positif. Dans de rares cas, cela se limitera à une analyse de contexte de quelques jours. Il m'est ainsi arrivé de recommander l'arrêt d'un projet pour des fonctionnalités incompatibles avec les situations d'usage (Ex : une application mobile avec de la saisie intensive). Si le client décide d'arrêter les frais, ce ne sont alors que quelques jours facturés pour des centaines de jours de développement économisés!

Heureusement, la plupart du temps, je parviens à proposer un plan d'action avec un ROI très significatif en restant compatible avec les moyens de mes clients, même sur des petits projets.

« L’ergonomie n’est pas réservée aux riches »

Une étude bien menée dans un contexte favorable doit logiquement amener à amortir l’investissement ergonomique dès la mise en production. A plus long terme, il est raisonnable d’espérer un ratio de 10 pour 1 à l’issue du cycle de vie de l’application.

Ceci étant sans compter le bien le plus précieux à mes yeux : des utilisateurs satisfaits !  

Suis-je un mouton à cinq pattes ?

L'idée de ce billet m'est venu suite à la parution d'une annonce recherchant un développeur C# avec des compétences en design/ergonomie. Elle a donné lieu à des échanges passionnés sur la liste ergoIHM, les uns raillant ces sociétés à la recherche de profils qui font « papa maman  » tandis que les autres se lamentent de la méconnaissance persistante du métier d'ergonome. Au lieu de chercher des moutons à cinq pattes, laissons les développeurs développer et les ergonomes analyser l'activité.

J'aurais bien aimé adhérer à cette classification rassurante si je ne m'étais senti directement visé.

Je fais en effet parti de ces rares olibrius qui, après une formation purement technique, ont eu l'outrecuidance de se tourner vers l'ergonomie. Après cette double formation suivie de 15 années de pratique en conception en implémentation d'IHM dans des contextes variées (SSII, grands comptes, PME, éditeurs), voici l'occasion de faire un retour d'expérience et de me remettre en cause.

Suis-je donc devenu un mouton un cinq pattes ? Que m'apporte donc l'ergonomie dans mon métier de développeur ? A moins que ce ne soit l'inverse ?

Pas n'importe quel développeur

Tout d'abord, il existe aussi des a priori sur le métier de développeur, qui sont malheureusement aussi véhiculés par des ergonomes.

Le développeur n'est pas un ouvrier spécialisé de la programmation, capable de pisser des lignes de code par unité de temps, quel que soit le langage informatique ! La vitesse d'évolution des technologies est telle qu'il est impossible de maîtriser toutes les façons de coder. On observe donc des spécialisations suivant :

•  l'écosystème: Microsoft (.net, Windows Phone), Oracle/Google (Java, android),  progiciels (SAP, X3, …)
• l'architecture applicative : front-office (architecture client  : IHM webs ou natives), back-office (architecture serveur  : modèle métier, base de données, EAI...)

En France, le métier de développeur est largement dévalorisé, car présenté comme un passage obligé, mais transitoire, pour les jeunes ingénieurs. Bref, pour faire partie de l'élite de demain, il est recommandé de passer chef de projet en moins de 5 ans.

Moralité : la plupart des développeurs sont des débutants, et ils ne veulent pas le rester.

Corollaire : les développeurs expérimentés sont rares et on les croit peu compétents.

Pour ma part, j'adore le développement, la construction d'une architecture applicative et l'écriture du code, sont des processus hautement créatifs, qui font appel à des capacités d'abstraction et une gymnastique intellectuelle très valorisantes. Cela colle avec ma vision, plutôt anglo-saxonne, du métier d'ingénieur.

Ainsi, alors que la plupart de mes camarades de promotion étaient attirés par les architectures matérielles et le côté serveur, j'étais pour ma part passionné par la réalisation des interfaces hommes machine.

Si par la suite, j'ai retrouvé cette inégalité d'intérêt entre le front et le back-office, j'ai aussi pu constater que la proportion de code entre le client (l'IHM) et le serveur était, en revanche, équilibrée. Autrement dit, statistiquement, la plupart des développeurs front-office (ceux qui implémentent les IHMs) travaillent sans véritable intérêt.    

Pas n'importe quel ergonome

En sortant de l'école d'ingénieur, je m'estimais bien formé sur les aspects techniques mais complètement à la rue sur les aspects humains. Et encore, j'avais eu la chance d'être sensibilisé par un tout nouveau module d'ergonomie !

Ma logique était simple : pour traiter correctement une problématique, il faut avoir une vision sous tous les angles possibles... A-t-on une représentation correcte d'une pièce de monnaie lorsqu'on ne voit que son côte pile  ?  Cela tenait de l'évidence : il me fallait voir de l'autre côté de l'écran, vers l'utilisateur final.

J'ai alors recherché une formation en ergonomie logicielle et me suis tourné vers le DESS d'ergonomie de Paris V. J'y ai trouvé l'essentiel, à savoir comment asseoir une conception d'IHM sur une analyse de l'activité ainsi que des fondamentaux sur l'être humain  : psychologie cognitive, limites physiologiques... Pour autant, la formation intégrait un aspect ergonomie physique, sans intérêt pour moi.  Tandis que les techniques liées à la conception d'IHM (outils de maquettage, composants graphiques, patrons de conception...) n'étaient qu'effleurés.

Cependant, la pratique de l'ergonomie ne saurait se résumer à l'analyse de l'activité. A mon sens, l'ergonome crée de la valeur par ses recommandations. L'analyse de l'activité lui permet de les légitimer mais ne constitue pas un livrable. Il ne faut pas confondre le moyen (l'analyse de l'activité) et la fin (des préconisations ou des spécifications). 

Or, de nombreux ergonomes, souvent issus d'un cursus universitaire en psychologie, éprouvent de grandes difficultés à élaborer des recommandations, en particulier dans le domaine des IHMs.

Je ne vois pas comment, sans aucune formation technique, on peut élaborer des propositions techniquement réalistes. Cela dit, il n'est jamais trop tard pour de se mettre à la technique et j'ai vu des psychologues passer de l'autre côté du miroir…

Mon retour d'expérience

 Ce que j'ai vécu en 15 ans n'est sans doute pas représentatif, mais c'est une réalité qui m'a permis de déconstruire certaines représentations   :

•         La pratique de l'ergonomie ne s'improvise pas

Faire simple, c'est compliqué. On ne devient pas ergonome en lisant un bouquin. Il faut une formation solide et beaucoup de pratique. Dans le domaine de l’IHM, cela ne se résume pas à connaître des guidelines, des composants graphiques et des patrons de conception. 

Concevoir une IHM, c'est faire des arbitrages entre des règles souvent contradictoires et tenter de coller aux objectifs et aux modes de pensée de l'utilisateur. Seule l'analyse de l'activité fournit les clés pour comprendre l'activité de l'utilisateur. Le designer d'interactions qui n'est pas ergonome est pour moi une coquille vide.

•         La présence d'un ergonome et d'un graphiste est loin d'être systématique

Mes étudiants d'IUT croient que la spécification et la conception de l'IHM sont systématiquement faite par une équipe spécialisée avec un ergonome et un graphiste ! Dès lors, inutile d'avoir des compétences dans ce domaine. CQFD… 

Effectivement, avec une approche cycle en V classique, on traite en principe les aspects IHM, en intégrant à la phase de spécifications, deux acteurs supplémentaires   : l'ergonome, qui réalise une maquette, et le graphiste qui fait l'habillage graphique. Éventuellement, on fait revenir l'ergonome en phase de recette métier pour faire un audit ergonomique ou des tests utilisateurs. 

Si ce type d'organisation existe, notamment sur les projets webs et chez certains grands comptes, il est loin d'être généralisé, notamment dans les PME et sur les applications internes de gestion. J'ai vu et je vois encore des développeurs concevoir leurs écrans «   from scratch » en cherchant des icônes via Google Image ! C'est fréquent, y compris dans certains grands comptes   !

Il est à la fois triste et paradoxal de constater que des catalogues en ligne bénéficient d'investissements ergonomiques importants pour une fréquence d'usage modérée, tandis que des applications de prise de commande, utilisées à longueur de journée, n'ont pas vu l'ombre d'un graphiste ou d'un ergonome. Comme si le fait que l'utilisateur soit captif pouvait dispenser d'optimiser sa productivité !

•         Le développeur est confronté à des problématiques ergonomiques.

Quand il n'est pas laissé seul face à la conception de l'IHM, le développeur sera quand même tôt ou tard confronté à des problématiques ergonomiques.

Souvent, les spécifications contiennent des maquettes ou des copies d'écrans, mais pas systématiquement. Maquetter l'ensemble des écrans étant un travail colossal, certains cas d'utilisation ne sont carrément pas illustrés. En outre, quand le temps du développement est venu, l'ergonome est bien souvent parti.  

A cela, s'ajoute des problématiques de faisabilité technique (composant graphique absent du framework avalisé par la DSI), conduisant à des adaptations plus ou moins heureuses des développeurs ! En phase de développement, on assiste parfois (souvent ?) à une déconstruction totale de l'IHM proposée par l'ergonome. Malheureusement, celui-ci n'est plus la pour se défendre, et il arrive que le livrable ne contiennent plus grand chose de ses propositions   !

•         Il existe une vraie complémentarité entre l'implémentation d'IHM et l'ergonomie

Le développeur est le premier utilisateur, au sens temporel du terme. Comme il est au plus prêt du code, s'il distingue un problème il est susceptible de le corriger à moindre coût. A l'inverse, si le problème n'est découvert qu'après la mise en production, il est souvent trop tard car le budget a été consommé ! 

C'est une réalité, les guides ergonomiques sont rarement mis en pratique par le développeur. D'où l'intérêt d'implémenter ces règles, car au final, c'est le code qui fait foi. C'est possible, sur certaines architectures techniques. J'ai en tête un projet pour un grand compte pharmaceutique, ou nous avons réalisé un framework graphique implémentant environ 50% des règles du guide d'ergonomie. L'ergonomie peut donc s'implémenter...

La spécification d'une IHM n'est pas déterministe, c'est à dire qu'à exigence ergonomique égale, il existe plusieurs IHMs possibles. Etre développeur m'aide à proposer la solution technique la moins coûteuse.

C'est en forgeant qu'on devient forgeron   : je ne connais pas de meilleur moyen pour connaître les composants graphiques et les patrons de design d'une plateforme, que d'implémenter une application.

Conclusion

S'il est clair que je n'entre dans aucune des cases habituelles, je ne pense pas être devenu un mouton à 5 pattes. Au contraire, je revendique la cohérence de mon parcours, autour d'un seul et même domaine d'étude : l'IHM. Je me sens bien comme ergonome car mon travail est basé sur l'analyse de l'activité et la connaissance des utilisateurs finaux. Je me sens bien comme développeur car c'est lui qui réalise in fine l'IHM mais aussi parce c'est une activité que je pratique avec plaisir.

Chacun trace sa route et loin de moi l'idée d'imposer une façon de faire ou d'être.

J'ai choisi de me spécialiser, non en fonction des stéréotypes des métiers existants, mais des compétences qui me semblaient utiles en conception d'IHM.  Je ne suis ni superman ni omniscient : je ne fais pas d'ergonomie physique,  j'ai délaissé les aspects design car je n'ai pas de talent artistique et j'ai choisi d'implémenter uniquement côté client dans l'écosystème Java afin d'avoir une réelle expertise.

Au final, je milite pour une démocratisation de l'ergonomie. Sortons l'ergonomie de ses niches habituelles (site web, téléphonie, IHM embarquées...) chez les grands comptes pour l'appliquer en PME sur des applications de gestion à usage intensif  !  Cela implique de sortir d'une pratique académique de l'ergonomie et de devenir pragmatique. S'adapter au budget limité du client sans sacrifier l'analyse de l'activité, proportionner l'effort ergonomique en fonction des fréquences d'usages. Ces projets ne peuvent pas toujours se permettre de faire intervenir un ergonome pendant tout le projet. 

Nous qui observons, chaque jour, des activités en environnement dégradé, ne pouvons-nous adapter la pratique de notre métier en contexte dégradé    ?  J'enseigne l'ergonomie en IUT informatique et propose une formation à destination des développeurs et les chefs de projet... En effet, quand l'ergonome ne peut pas être là, je préfère cent fois avoir des développeurs avec une sensibilité ergonomique.  

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.