Ice Cream Sandwich : bilan après 6 mois ?

Ice Cream Sandwich (ICS pour les intimes ou encore Android 4.0) est arrivé il y a maintenant 6 mois, accompagné par le dernier né de chez Google (et Samsung) : le Galaxy Nexus. Cette version avait pour but principal de réunir les tablettes et les smartphones, mais pas seulement. Android 4.0 comme on dit chez nous est en une sorte de version mûre d’Android, qui petit à petit prend l’allure d’une certaine renaissance. Mais en 6 mois d’existence, il peut être intéressant de faire un véritable bilan de cette version que l’on peut considérer comme réellement importante pour le monde d’Android et le(s) futur(s) qu’on pourrait lui entrevoir.

 

Difficile de se tromper : ICS, c’est un peu comme si Android renaissait de ses cendres. Et en voyant la version précédente, pas étonnant que certaines tablettes aient fini comme ça.

 

ICS a apporté quelque chose d'important qui lui faisait cruellement défaut : une charte graphique soignée, de quoi permettre aux développeurs de produire des applications qui, sans être identiques pour autant, donnent l'impression d'une continuité visuelle grâce à Holo, ce nouveau thème partiellement introduit avec Honeycomb (3.0 à 3.2) qui fera désormais office de vitrine pour le système.

Google se doit de donner l’exemple dans ce domaine, et on peut dire que c’est assez réussi : toutes leurs applications y sont passées. Enfin, Google a renforcé sa communication autour des guidelines (ligne de conduite) de ce qui semble être l’identité visuelle définitive d’Android, et je ne peux que citer l’excellent site mis à disposition des développeurs pour expliquer et montrer chaque détail de ce que se veut être Android.

Cette histoire de recherche d’identité visuelle peut paraître purement cosmétique, voire superficielle, mais en réalité il en est bien plus que ça. Voilà un an et demi que je lis les sujets concernant Android sur divers forums, sur les commentaires de news de plusieurs sites (que ce soit en français ou en anglais d’ailleurs) mais également de part l’expérience que j’en ai auprès de connaissances, d’amis, de la famille parfois,  le constat a plusieurs fois été le suivant : Android c’est moche. Oui, pour nous autres technophiles, l’aspect graphique est souvent compensé par le système en lui même, et souvent parce que l’on connait toutes les combines pour remédier plus ou moins à ce problème. Mais l’utilisateur lambda, qui veut juste un smartphone, alors un téléphone beau, avec une interface qui envoie, a de grandes chances d’être celui qui lui convient : c’est pratiquement toujours sa première impression et souvent la dernière lorsqu’il n’est pas satisfait. Après, on peut parler des goûts et des couleurs, mais ce que j’ai pu en voir m’a amené à penser que malgré les qualité de l’OS, Android manquait d’un sérieux support graphique. Et je ne parlerais pas, bien sûr, du nombre aberrant d’applications toutes avec un design différent, provoquant ce sentiment que l’OS n’a aucune unité (ce qui tendait à disparaître néanmoins avec Gingerbread).

 

En résumé, Android veut se détacher de son image de “système de geek trop compliqué”. Et on ne peut que lui souhaiter !

 

Je citerais également le post de Jake Wharton sur Google+, lui-même développeur Android et à l’origine d’ActionBarSherlock, une librairie permettant de rendre compatible l’ActionBar avec les versions 2.3 et moins. Pour rappel, l’ActionBar est l’un des éléments d’interface fondamental d’Ice Cream Sandwich, sorte de menu où sont rangées les fonctions principales de l’application. Son interprétation est tout à fait correcte, dans le sens où le but d’un développeur n’est pas de mimer l’interface Holo classique, mais bien de s’en inspirer pour donner à son application une identité propre.

Ce choix de Google pourrait paraître discutable, voire critiquable dans le sens ou la firme pousse les développeurs à adopter une ligne de conduite, mais il faut voir ceci comme une suggestion pour faciliter la compréhension des utilisateurs. Aujourd’hui, personne n’a envie d’apprendre à se servir d’un programme, l’utilisateur veut pouvoir utiliser l’application dès son ouverture, que tout soit simple et intuitif, tandis que certains seront de l’avis d’Alex Yumashev, c’est-à-dire “90% des utilisateurs sont stupides”, et donc que cette uniformité permet de palier à ce problème. Et pourtant, c’est également ce qu’à fait Apple avec iOS, et le résultat est là : iOS n’a besoin que d’un bouton pour fonctionner, là où Android en utilise 3 (avec ICS), pour beaucoup Android est bouillon là où iOS est intuitif (mais encore une fois, c’est aussi une histoire de goûts et de couleurs).

Bien évidemment le bleu n’est pas au goût de tout le monde, mais en voyant tout le système on peut imaginer que, dans le futur de l’OS, la couleur sera modifiable et donc tout le système pourra être customisé (quel bel anglicisme !) pour que l’utilisateur puisse s’approprier l’OS.

Au delà de l'amélioration visuelle et ergonomique, Holo répond à deux problématiques des développeurs. Dans un premier temps, ce thème est à présent obligatoirement intégré et laissé tel quel. Ceci assurera au développeur que son interface s'affichera de la même façon sur tous les terminaux. Actuellement, Motorola ou Samsung, par exemple, ne propose pas les thèmes standards. Pour leurs terminaux, une couleur, claire de base, peut devenir sombre, ou un élément graphique peut grossir ou rétrécir. La lisibilité de l'interface peut en être massacrée. L'autre aspect est lié à la gratuité des outils de développement. Faire sa propre application pour un développeur connaisseur du Java (premier langage informatique en entreprise) est assez facile, et les outils se téléchargent gratuitement. Du coup, de nombreux développeurs se lancent sans s'allier avec un graphiste. Ce qui donne comme résultat un lot gigantesque d'applications où l'innovation est ternie par une interface de mauvaise qualité. Google offre maintenant beaucoup plus d'outils aux développeurs pour mettre en place facilement les bases d'une interface de qualité, le graphiste apportera de la différentiation et l'identité.

On ne peut que souhaiter à Google de continuer sur cette voie et bien sûr de ne pas changer trop vite cette guideline : pour l’utilisateur final elle promet d’être un réel bénéfice mais aussi pour le développeur lui permettant de s’abstraire le plus possible de toutes les contraintes de design et d’expérience utilisateur pour se concentrer sur ses idées et ce qui donne ce caractère unique à son application.

 

Peut-être un jour pourra-t-on switcher du bleu au violet, ou au rouge… Ou pourquoi pas à l’arc-en-ciel tiens ?!

 

Un point légèrement controversé est la réunion des tablettes et des smartphones sous un même OS, et donc techniquement d’une meilleure approche pour le développeur pour la création de son application sur les deux supports. Une bonne, une excellente idée même, puisqu’après tout, Honeycomb, de l’aveu même d’Andy Rubin, est un OS immature et sujet à de nombreux problèmes de stabilités et de performances (et j’en ai fait les frais vous pouvez me croire). Honeycomb est très proche d’ICS, c’est même lui qui fait office de base à ce qui est destiné à devenir Android, dont par exemple la disparition des touches hardware, l’accélération matérielle, la nouvelle interface pré-ICS, etc. Honeycomb, c’est un peu l’adolescence d’Android : c’est plein de bugs, ça fait pas toujours ce qu’on veut, ça peut provoquer parfois de jolies crises de nerf, on sent que ça se veut mature mais y a encore plein de choses à corriger. Mais  Android 4 peut-il changer la donne ?

Oui, sans doute. Sans doute ? Encore faudrait-il que nos chères ardoises (francisation quand tu nous tiens) reçoivent un jour cette nouvelle version. Même la tablette la mieux vendue du monde Android, la Galaxy Tab 10.1 (et 8.9) est toujours sous Honeycomb. Seul Asus, Motorola (et encore, puisque c’est Google qui s’occupe de la mise à niveau de la Xoom) et Archos (comme quoi) ont daigné faire ce qu’il fallait pour corriger le tir. Oui, ICS règle les problèmes d’Honeycomb, ce n’est pas le Saint Graal puisque le Tegra 2 très largement majoritaire n’est pas une foudre de guerre, mais c’est suffisant pour donner à l’utilisateur un confort bien mérité après avoir essuyé les platres. Ice Cream Sandwich a donné une nouvelle vie au marché des tablettes android, sans nul doute mis à mal par une version lancée trop rapidement et clairement en deça de ce que pouvait être l’iPad son principal concurrent. La démarche de sortir de nouvelles tablettes avec un système désormais prêt est tentante, et ce serait même normal : repartir sur de bonnes bases ne peut être que bénéfique après l’échec relatif des premières tablettes. Mais tout ça mène à ce qu’on peut considérer comme le plus gros défaut d’android : la répartition des versions d'android sur le marché.

 

Finalement, les tablettes Android ne se vendent pas si mal, mais peut-être parce que l’iPad 2 à ce moment là était sorti depuis longtemps ?… (via TechCrunch)

 

Oui, la «fragmentation» (mettons entre guillemet car il ne s'agit pas d'une fragmentation pure et dure comme on l'entendait au temps de J2ME et de Symbian). Fragmentation qui est due tout simplement au choix de Google quant à la distribution d’Android (en open-source je le rappelle). Et à vrai dire, son ouverture est une force : la possibilité pour un utilisateur d’avoir le choix est un avantage considérable (face à son principal concurrent). Le choix du constructeur, le choix de l’appareil, le choix du prix. Et pourtant, cette fragmentation est certainement son plus grand défaut. Je ne me placerai pas du point de vue utilisateur mais développeur : nous sommes en avril 2012, soit 6 mois à quelques jours près du lancement officiel de la dernière version Ice Cream Sandwich, et pourtant, quelle est la part de cette version parmi tous les mobiles Android ? 2,9%. Oui, une version censé être majeure boudée par les constructeurs. Pas tous, c’est vrai, mais combien d’appareils ont actuellement reçu cette version ? On peut les compter sur les doigts d’une main (ou de deux à la limite). Ce problème de version est lié à l'inertie de la montée de version par les constructeurs (mon téléphone est en version X et le constructeur tarde à mettre à jour vers X+1). Mais jusque là, cette latence est compensée par la sortie de téléphones directement dans la dernière version. Or depuis 6 mois, peu de nouveaux téléphones sont sortis.

 

Oui, il s’agit bien de la répartition des versions en Avril 2012… (via Android.com)

L’ouverture d’Android constitue un frein pour son développement, c’est le constat malheureux qu’il faut y voir : les constructeurs y ajoutent leur propre interface graphique qui, souvent, ralentissent, voire empêche les mises à jour pour des raisons de temps de dévelopemment ou de coûts. Je prendrais l’exemple de Samsung et du Galaxy S qui ne recevra donc jamais ICS pour cette raison, alors que son pendant chez Google (le Nexus S) est parfaitement compatible. Les constructeurs personnalisent le téléphone, ce qui aurait pu être compréhensible en voyant les anciennes versions d’Android, et ces interfaces sont souvent très (trop) lourdes. Peut-on pour autant en vouloir à Samsung dans ce cas ? Pour les “core users”, cette réponse de la part du géant coréen est purement marketing (et ils ont sans doute raison), mais prenons le cas des utilisateurs dits “normaux” : pourquoi devoir réapprendre à se servir de son téléphone, alors qu’il fait déjà les choses comme il faut ? Mais lorsque j’entends ça (et pourtant de la bouche de technophiles), c’est mon petit coeur de futur développeur qui souffre : parce que oui, on n’y pense pas, mais les mise-à-jour apportent leur lot de nouvelles APIs, et donc de possibles nouvelles fonctions, de simplifications et donc d’améliorations. Quel développeur sur le marché, et j’entend par là un développeur qui souhaite réellement être rentable et non pas faire ça pour le plaisir, perdra du temps à créer une application dédiée à une version qui n’est utilisée par au mieux que 2.9% des utilisateurs ? Aucun. Bien sûr, rendre compatible une application vers une version antérieure reste possible, bien que cela rajoute du travail en plus (et donc une maintenabilité du code plus difficile). Distribuer plusieurs apk aussi, mais c’est une mauvaise solution, car une fois de plus on multiplie les versions.

Rajoutons à tout cela les couches opérateurs qui ralentissent le processus et un mobile restera sur sa “pauvre” version Gingerbread ad eternam.

Il est quand même bon de noter que Google a annoncé, il y a un an, ralentir l'arrivée des nouvelles versions pour que les constructeurs puisse suivre. Et c'est effectivement le cas. Il faut laisser temps aux constructeurs de changer leur mentalité, car maintenant, il n'ont plus d'excuse.

Mon constat ? Android 4.0 est sorti bien trop tôt. Peut être aurait-il fallu attendre la nouvelle vague de smarphones (l’actuelle donc, avec les HTC One, les nouveaux Xperia, les futurs Samsung, pour les plus importants) avant de proposer une nouvelle version. Ou peut-être un véritable rapprochement de Google et des constructeurs, pour proposer des mise-à-jour plus rapides serait bénéfique. Et pourtant je me place du côté de la communauté “dev” / core-users, qui attends avec impatience chaque nouvelle version, chérissant l’Android Open Source Project pour avoir des versions dénuées de toute interface constructeur, aimant “bidouiller” mon portable jusqu’à le rendre parfois complètement instable. Je ne pense pas qu’il y ait pour l’instant de solution miracle qui puisse à la fois contenter la grande majorité des consommateurs, mais je suppose et j’espère que cette renaissance d’Android est un signe que ceci pourrait changer : un premier pas avec la signature par les constructeurs d’un contrat garantissant la mise-à-jour de leurs terminaux pendant 18 mois a été fait par Google il y a un an, peut-être le géant du web saura-t-il nous étonner dans 2 mois à la Google IO ? Tout est possible.