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.

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

Introduction

Les applications mobiles ont le vent en poupe. Chaque société veut mettre à disposition son site mobile, question d'image. Ca me rappelle les années 2000 avec la frénésie du web. Là encore, il faut bien disjoindre les applications vitrines destinées à donner une image commerciale de modernité et les véritables applications mobiles prenant en compte l'itinérance de l'utilisateur.

Comme pour les applications classiques, je suis souvent confronté au dilemme sur l'approche à tenir : application web ou application native. Ce choix est devenu est véritable débat, la plupart du temps alimenté par les seuls techniciens. En tant qu'ergonome, je me lance pour parler sous l'angle de l'utilisateur final.  En tant que technicien, c'est le retour d'expérience d'un vieux briscard de l'implémentation d'IHM.

Origine du débat

La montée en puissance des smartphone et des tablettes pose des problèmes majeures aux DSI. En effet, la profusion de device s'accompagne d'une pléthore de système d'exploitation, chacun proposant son ergonomie et son environnement de développement associé (android SDK/Java, Xcode/Objective C...). Les problématiques évoquées le plus souvent sont les suivantes : 

• Comment adresser l'ensemble des plateformes sans exploser les coûts de développement ?
• Comment vais-je trouver des développeurs compétents dans toutes ces technologies ?
• Comment maintenir sur le long terme si le code est redondé sur chacune des plateformes ? 

La réponse est pourtant simple, HTML5 sachant par définition tout faire, je vais résoudre mes problèmes en faisant une application Web : 

• Le code de la couche de présentation étant factorisé, je ne maintiens qu'une seule base de code
• Je n'ai plus besoin de compétences spécifiques, des développeurs Web, plus faciles à trouver et donc moins chers, suffisent. 
• Toutes les plateformes supportant HTML5, je ne gère plus qu’un seul environnement de développement

Sur le papier, la démonstration est imparable et la solution séduisante. Les arguments sont en effet recevables mais doivent être relativisés :

• Les applications webs font elles aussi cohabiter plusieurs langages (CSS, Javascript, html, framework  web) : un bon développeur Javascript n'est pas aussi facile que cela à trouver 
• A l'usage, il peut subsister du code spécifique en fonction du navigateur. Ne déplace-t-on pas le problème, avec une application multi plateforme, certes, mais pas multi navigateurs ?
•  Il n'y a pas tant de code que cela pour la programmation des UI mobiles, ces applications sont souvent très simples. Au delà de 10 écrans, on peut s'interroger sur leur pertinence ergonomique. Rappelons que Apple recommande des applications mono fonctionnelles.
• En terme de part de marché, adresser 2 voir 3 plateformes semble suffisant. Aux USA, Android et IOS occupe 80% du marché. Etant donné la fragmentation de la part de marché restante, quel est l'intérêt économique d'adresser des plateformes supplémentaires ? 

Les considérations techniques

Je n'ai pas connaissance d'autres arguments en faveur du développement web mobile. Voyons maintenant la réalité d'un point de vue technique. On a deux types d'approches pour le web mobile :

• Site web mobile : application web classique dont le rendu est adaptée à la taille réduite de l'écran
• Solution hybride (type phoneGap ou Titanium) : utilisation d'un framework faisant tourner une vue web dans une application native, ce qui permet de déployer l'application sur le market (App Store, Google play…) et de lever certaines limitations techniques (Ex : accès à la plupart des capteurs du device). 

Dans les deux cas, on peut chercher à approcher le rendu natif : cette approche type "canada dry", fait dire aux partisans des applications webs que ces applications n'ont rien à envier aux applications natives. Les applications natives seraient-elles donc promises à une mort certaine ?

Pas si sûr, car, en introduisant une couche d'abstraction supplémentaire, les solutions hybrides posent les problèmes suivants :

• Effet boite noire de la couche d'abstraction : difficultés à customiser le rendu visuel du code natif généré.
• Risque de régression accrue sur un code factorisé entre plate forme : une correction pour une plate forme risque de déstabiliser les autres.
• Le natif a toujours un coup d'avance sur le framework : le décalage fonctionnel est inévitable entre la couche d'abstraction et la dernière version de l'API graphique (Ex: les nouveaux composants Android 4.0 sont-ils supportés ?).
• La couche intermédiaire a fatalement un effet négatif sur les performances et donc la réactivité de l'IHM, qui sera indexé aux performances du navigateur pour le rendu HTML et l'exécution de code javascript.

D'autre part, et c’est un élément souvent ignoré, la productivité des solutions natives est très bonne grâce à une excellente ergonomie de développement :

• Debugage en temps réel sur le device permettant d’identifier rapidement tout problème, y compris ceux liés à l’interface tactile)
• Temps de cycle entre correction dans le code et visualisation du résultat sur le device au plus court (de 1 à 3 mn sur Android)

Ceci est à mettre en perspective avec la productivité des applications Webs qui est loin d'être démontrée. Certains problèmes (liés au comportement de l’IHM) ne se produisant que sur un device, sont très difficilement identifiables, conduisant à des séances de débogage « dans le noir », avec une démarche de type essai/erreur. Or comme, il faut parfois plus de dix minutes entre l’essai et le résultat sur le device (temps de compilation et de déploiement), on peut passer des jours à corriger des bugs d’affichage.

Hormis la courbe d'apprentissage initiale et la réticence aux changements des développeurs habituées à la programmation web, je doute du retour sur investissement concernant les coûts de développement. Au-delà de 20% de code spécifique, on perd l’intérêt de la factorisation. En dessous de 3 plateformes à adresser, les gains liés à la factorisation sont contrebalancés par une perte de productivité. Ainsi, si l'on adresse uniquement les 2 plateformes se taillant la part du lion sur le marché, on est à mon avis en dessous des coûts d'une solution unique web.

La maturité

Le développement natif permet l'accès à toutes les ressources matérielles et logiciels du device, de façon mature :

• Accès aux capteurs (GPS, accéléromètre....)
• Accès aux données du téléphone
• Accès aux autres applications (Agenda, Contacts....)

Si cela n’est pas impossible en Web, c’est à la fois plus difficile et moins mature. En outre,  le support de HTML5 sur navigateur mobile demeure problématique et l’on se retrouve avec une situation similaire avec celles des navigateurs desktop du milieu des années 2000 ;

• Support inégal de HTML 5 entre les navigateurs mobiles : le pire étant celui d'Android, (véritable Internet Explorer de la mobilité)
• Risque de code spécifique en fonction du navigateur
• Même les solutions hybrides ne parviennent pas à se connecter aux autres logiciels du système (agenda, contacts..).

Les considérations ergonomiques

Comme pour les applications web classiques, le choix web conduit, selon moi, à une expérience utilisateur dégradée

•  Le choix des composants graphiques limité à ce qui fonctionne partout : notion de plus petit dénominateur commun ergonomique
•  Gestion approximative de la taille des écrans : la difficulté à réaliser une application web plein écran (sans barre de défilement), fait tellement exploser les coûts qu'on en arrive à faire des IHMs en taille fixe, soit trop grandes (sur les petits écrans), soit trop petites (sur les gros écrans)
• Gestion approximative des interactions tactiles : l'ergonomie web n'est pas conçue pour le tactile, les gestures sont à recoder en HTML5 (avec le risque d'incohérence avec le gesture natif).
• On peut se poser la question sur la prise en charge d'autres fonctionnalités en web : basculement portrait/paysage, retaillage des ressources graphiques sans effets d'étirement (type nine patch en Android)...
• Le surcout des améliorations ergonomiques est tellement élevé (Ex : faire une IHM web redimensionnable sur plusieurs navigateurs), qu'au mieux il compromet gravement les gains sur les coûts de développement. Plus souvent, il conduit à faire de graves concessions sur l'ergonomie (Ex : IHM en taille fixe)  

L'ergonomie des applications dépend de la plate forme

• Les variations entre plateforme dépassent le simple rendu visuel des composants graphiques (skin)
• Les composants graphiques ne sont pas les mêmes entre plateforme (Ex : equivalent du splitView iOS en android, équivalent des tile Windows Phone)
• L'imitation du rendu natif en web est une mauvaise pratique : on perd la factorisation si on reproduit l'ergonomie de chaque plateforme, on pénalise les utilisateurs des autres plateformes si on choisit l'une des ergonomies.
• A moins d'enfreindre la règle de cohérence avec le système d'exploitation, la seule ergonomie possible est une ergonomie web dont les normes semblent très mal connues en situation de mobilité.

Conclusion

D'un point de vue technique, le développement Web est loin d'avoir démontré sa productivité. A niveau de compétence égal, il est à mon avis au moins deux fois moins productif qu’un développement natif pour une expérience utilisateur très inférieure. La réduction des coûts de développement est un leurre : ce qu'on gagne en factorisation on le perd en tests et en code spécifique pour gérer les différences entre navigateurs et maintenir une ergonomie acceptable.

Plus grave, à mes yeux d'ergonome, le choix du web conduit selon moi, immanquablement à une expérience utilisateur dégradée. Ainsi, choisir l'application web revient à arbitrer en faveur de la technique au détriment de l’utilisateur. C’est à mon sens, ce qui s’est passé avec la venue des applications web dans les années 2000, avec un recul ergonomique des applications webs par rapport à leurs ancêtres en client/serveur, certes plus difficiles à déployer, mais tellement plus adaptées. Cependant, les exigences ergonomiques des applications mobiles sont bien plus importantes : l’utilisation en situation de mobilité impose une ergonomie optimisée, la taille des écrans et les nouveaux modes d’interactions changent la donne, les utilisateurs mobiles sont également très exigeants. Bref, ceci ne me semble pas compatible avec les contraintes des applications webs.

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

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

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

Ainsi, si ces débats sont sains, il ne faudrait pas qu’ils cachent d’autres problématiques, tout aussi importantes, lorsqu’on aborde un projet mobile :

• Comment adapter mon application à une utilisation en mouvement ?
• Comment adapter mon application à l'interaction tactile ?
• Comment adapter mon application à un écran si petit ?
• Comment mon application va-t-elle exploiter les fonctionnalités spécifiques à la mobilité (géo localisation, appareil photo...) ?