Il y a quelques jours, Apple démarrait (en trombes) les ventes de ses nouveaux iPads, dont l’iPad mini. Cette tablette de 7 » semble promise a un bel avenir. Mais voilà, passé l’effet Waouh propre aux produits de la Pomme, on a vu fleurir quelques tweet signifiants que l’iPad mini utilise le même User-Agent que son grand frère de 10 ». J’ai notamment réagi au tweet de Maximiliano Firtman (@firt) qui soulignait ce point, en arguant, un peu vite (140 caractères obligent) que « les User-Agent, c’est le mal » (si vous ne savez pas pourquoi, la conférence de Rudy Rigot à Paris Web 2012 devrait vous aider à y voir plus clair). Twitter n’étant pas propice aux discussions de fond, Maximiliano s’est donc fendu d’un billet de blog où il explique que si l’iPad mini n’est pas distinguable de son grand frère côté serveur, il ne l’est pas plus côté front : les 2 tablettes annoncent la même densité de pixel (fausse, au passage), la même résolution, le même ratio… Bref, tout pour nous faire croire que les deux écrans sont identiques (oui, parfois, le front-end vous ment). Pas de recours au media-queries donc, pas d’utilisation possible du JS non-plus. Pour le moment, l’iPad mini utilise une version modifiée d’iOS qui peut être identifiée, mais ça ne durera pas.
Parce que le problème ne se limite pas uniquement a des soucis statistiques, il touche aussi – et surtout – nos composants d’interfaces. Car tout s’affiche plus petit de 19 % sur l’écran de l’iPad mini et que celui-ci se fait passer pour un écran de 10 » aux yeux de l’OS. Certes, Apple a introduit avec iOS6 l’auto-layout, un dispositif capable de recalculer de façon automatique le layout des interfaces pour optimiser leur position à l’écran. Malheureusement, celui-ci n’est pas disponible au sein de webview, le composant d’affichage web. Pas d’issue pour le moment…
Beaucoup de problèmes à venir donc : avec un écran plus petit, mais qui se fait passer pour un plus grand, il va être de plus en plus complexe d’optimiser les interfaces. En voulant limiter la fragmentation du marché de ses iDevices, Apple risque fort avec ses choix de provoquer une houle dans le petit milieu des développeurs.
Ceci étant posé, on peut néanmoins légitimement se demander si tout ça n’est pas tempête dans un verre d’eau. Beaucoup de développeurs semble s’émouvoir de la difficulté à identifier correctement l’iPad mini et à le différencier de son grand frère.
A mon sens, tout ceci n’est pas dramatique et le soufflé va retomber rapidement. Mais c’est une première étape et on risque fort de se trouver coincés dans certaines impasses à l’avenir. Structurellement, il y a peu d’intérêt à savoir si le périphérique est un iPad mini ou une tablette Android, ça n’intéresse que les statistiques… Par contre, il semble important qu’un écran de 7 » me signale bien son ratio et sa densité de pixels pour adapter les composants d’interfaces (notamment les zones cliquables de boutons, etc), et non qu’il se fasse passer pour un 10 » (ce qui est le cas de l’iPad mini). Pour le moment, c’est n’est pas trop grave, mais il faudra veiller à la fragmentation.
Ou plutôt : il va falloir revoir assez profondément la façon dont on conçoit nos interfaces en utilisant beaucoup plus les possibilités qui arrivent en CSS, SVG, etc en se détachant des contraintes matérielles.
Nicolas Hoizey
7 novembre 2012
Attention, Maximiliano a mis à jour son billet pour indiquer que son test sur une taille de 10 pouces n’est pas valide :
Je pense comme d’autres que c’est une tempête dans un verre d’eau, que la véritable solution à ce genre de problème devrait être la possibilité de choisir sa taille de caractère de base, comme dans les navigateurs desktop.
Ainsi, un design calé en unités
emet avec des Media Queries aussi enemn’aura aucun soucis.Aurelien Masfrand
7 novembre 2012
À mon avis, le but de l’ipad mini derrière est de proposer un ipad moins chère pour les personnes qui ont une bonne vue et des petits doigts.
Avoir des sites avec une interface optimisée type smartphone au lieu de tablette n’est pas du tout le souhait voulu par Apple derrière. C’est sûrement pour cela qu’ils le font passer pour un grand en falsifiant sa carte d’identité (oui, comme pour les ados qui veulent aller en boîte).
C’est un peu comme les consoles 3DS XL, avec pour cible des personnes souhaitant un meilleur confort visuel.
Je dirais qu’il ne faut pas se préoccuper plus que ça de ce nouveau device, juste tester les points bloquants, et évidemment permettre à l’utilisateur de configurer sa taille de police.
Matthias Dugué
7 novembre 2012
Sachant que Safari mobile ne propose toujours pas de personnaliser sa taille de corps de base (il me semble), le proposer dans l’interface comme une personnalisation de l’affichage a de nouveau du sens à mon avis…
Après, il faut espérer que ce nouveau device accélère la mutation vers les interfaces « bien conçues » avec des tailles en em, des media-queries adaptées au contenu et non au périphérique, des composants d’interfaces en SVG / Gradient CSS / Icon-font et des éléments interactifs construits sur des ratios (en em ou en %) et plus en taille fixe…
On en parle depuis longtemps dans les conférences qualité / accessibilité et dans les articles techniques ; on le voit encore trop peu en place. Souhaitons que le nouvel arrivant bouge un peu les choses.
jpvincent
7 novembre 2012
Le problème pour moi est un peu plus large que l’arrivée d’un mini.
Même lorsque tu fais bien fait les choses avec du responsive dans tous les sens, il reste que tu n’as finalement aucune idée de la taille physique de ta page. Jusqu’ici, les recommandation de tailles en pixels ou même en em des boutons se basaient sur la largeur d’un doigt moyen, par rapport à la largeur d’un iPhone, standard de facto des smartphones.
Avec l’iPad, une autre taille de bouton était utilisée, mais la plupart des tablettes android vendues étant plus petites, les utilisateurs pouvaient être génés. Comme l’iPad était ultra dominant sur tablettes, ça ne dérangeait finalement pas les concepteurs d’interface.
Maintenant que l’iPad mini rejoint la troupe des android, les designers commencent à s’en rendre compte, d’où le tollé :)
Cela dit, techniquement ça serait vraiment sympa qu’on connaisse la taille en centimètre du viewport :)