Créer un site Web mobile, approche pragmatique

On nous l'annonçait pour 2013, voilà que c'est arrivé en 2011. Une étude publiée par le cabinet de recherche Flurry en juin dernier montre que le temps passé sur Internet via les applications mobiles des smartphones et des tablettes a pour la première fois dépassé celui que les internautes passent sur le Web via les ordinateurs de bureau et les ordinateurs portables. Autant dire que l’Internet mobile n’en finit pas de prendre son envol et qu’un site web moderne ne peut plus se passer aujourd’hui d’une version mobile.

Retour aux sources

La décennie 2000 fut celle du Web et du Web 2.0, des standards W3C et de Firefox. La décennie 2010 sera celle du Web mobile, du Web design réactif, des tablettes et des navigateurs Webkit (Safari, Chrome, Konqueror...), les navigateurs les plus en avance aujourd'hui. 

Développer un site Web mobile semble au premier abord quelque chose d'assez simple : ce n'est jamais que du Web avec des styles CSS adaptés à une résolution d'écran plus petite. Mais quand on y regarde de plus près, cela devient rapidement plus compliqué, en raison de la multiplicité des plateformes, navigateurs, résolutions d'écran, qui pourraient nous amener à créer un site pour chaque type de terminal, si nous n'y prenons pas garde. Comme dit Ethan Marcotte, à ce rythme là, où va-t-on. Va-t-on développer un site pour iPhone, un site pour iPad, un site pour le Nokia N90 ? Est-il dans nos possibilités de continuer à encourager chaque nouveauté possédant son système sur-mesure ? Mais aussi en raison d'une certaine fermeture due au fait que l'Internet mobile, contrairement au Web, est une aventure largement propriétaire, avec des firmes qui imposent leurs standards comme du temps de la première guerre des navigateurs, et ce, malgré une certaine ouverture fort appréciable due à l'emploi des standards HTML5 et CSS3, largement en avance dans les navigateurs mobiles. 

Coder pour le Web mobile, c'est donc revenir à l'origine des problématiques de conception Web. Un retour aux sources qui, pour LEKTUM, signifie de repasser par certains sites web incontournables, comme OpenWeb ou Alsacreations, qui nous avaient tant guidé à nos débuts, en 2003, et bien entendu l'incontournable A List Apart. L'article Adapter un site pour les smartphones d'OpenWeb donne par exemple de précieux points de repère, dont nous reprendrons ici une partie. L'article princeps d'Ethan Marcotte sur le Responsive Web Design sur A List Apart est quant à lui exemplaire (traduction disponible ici). Bien sûr, on peut perdre passer pas mal de temps à lire tout un tas de recommandations officielles ou non, complètes ou abrégées, sur les bonnes pratiques en matière de code pour le Web mobile. Mais nous pensons que ça ne sert pas à grand chose. Dans le même esprit que la série de livres A Book Apart, nous n'avons pas beaucoup de temps pour lire des textes purs et complets, et préférons lire des choses brèves et pragmatiques, afin de vite retourner au travail. Aussi cet article s'attachera à faire le point de manière synthétique et pragmatique, en allant directement au concret, et en n'hésitant pas à reprendre des bonnes choses lues ailleurs. Avis aux amateurs !

Les résolutions

Une certaine diversité...

C'est là que les problèmes commencent, étant donné la variété des devices. Le service Mobify, qui se targue d'être compatible avec plus de 6000 devices, signale rien moins que trois “standards” de résolutions pour couvrir toutes les possibilités :

  • 320x420 (largeur x hauteur en position portrait)
  • 240x320 (largeur x hauteur en position portrait)
  • 240x260 (largeur x hauteur en position portrait)

Mais, c'est sans compter avec certaines particularités de nos smartphones et tablettes préférés ! Let's have a look at the iPhone devices.

iPhone 3, une résolution d'écran de 320x480

La résolution native de l'iPhone3 est de 320x480 pixels (largeur x hauteur en position portrait, ce qui donne l'inverse en position paysage quand on le renverse). Ainsi, lorsqu'on fait une capture d'écran depuis un iPhone 3GS dans Safari, on obtient l'image suivante, reproduite ci-dessous à l'échelle 1 :

iPhone 4, une résolution d'écran de 640x960

Innovation oblige, l'iPhone 4 est doté d'un écran Retina à 326 ppp (source : Apple), ce qui lui donne une résolution doublée : 640x960 pixels (largeur x hauteur en position portrait). La même capture d'écran depuis un iPhone 4 dans Safari donne l'image suivante reproduite aussi à l'échelle 1 :

Attention, iPhone 3 et iPhone 4, une même taille d'écran !

Mais attention ! Ne pas confondre résolution d'écran (software) et taille d'écran (hardware). La taille physique de l'écran est la même sur l'iPhone 3G(S) et l'iPhone 4 : ils sont dotés tous les deux du même écran 3,5 pouces. Comme l'explique très bien Apple, c'est simplement la densité de pixels qui change avec l'iPhone 4 — 326 pixels par pouce (dpi) —, ce qui confère au texte et aux graphismes une apparence parfaitement nette dans toutes les tailles (voir la démo comparative officielle). Un écran de 3,5 pouces, c'est grosso modo un écran qui a une diagonale de 9 cm (9 divisé par 2,54 = 3,543... étant donné que 1 pouce = 25,4 mm = 2,54 cm) et des dimensions d'environ 7,5cm x 5cm (à la louche, après vérification sur un modèle perso).

Ce qui semble vouloir dire qu'un design de 640px de large s'affiche comme 320px dans un iPhone 4 mais avec une meilleure netteté (donc vaut mieux en tenir compte). Voir plus bas à propos du Viewport.

iPad, une résolution d'écran de 768x1024, retour au Desktop  ?

Quant à notre ami l'iPad, il est doté d'une taille d'écran de 9,7 pouces, soit une diagonale visible de 24-25cm pour une résolution d'écran de 768x1024 pixels (largeur x hauteur en position portrait) à raison de 132 pixels par pouce (ppp), ce qui lui confère en position paysage la résolution classique de référence des versions Desktop (1024x768). Notons au passage qu'il ne s'agit pas là d'un écran Retina et que, sans doute, la prochaine version de l'iPad en sera équipée, bouleversant encore ces chiffres. La même capture d'écran sur iPad, échelle 1 :

Que faut-il retenir ?

Il y a 3 cas de figure à prendre en compte : 

  • les versions Desktop classiques, pour lesquels la résolution de référence reste 1024 px en largeur, ce qui permet de travailler en 960px via une technique de "Grid" de type 960gs.
  • les tablettes tactiles de type iPad, sur lesquelles le site s'affiche minimum en 768 px de large (en position portrait) [l'avantage est qu'en position paysage, on se retrouve sur une version Desktop], ce qui permet de travailler par exemple en 720 px via une technique de "Grid".
  • les terminaux mobiles de type smartphones, sur lesquels le site s'affiche minimum en 320 px de large en position portrait [ attention, ça ne couvre pas toutes les possibilités, les plus vieux smartphones sont sur 240 px de large ] ou 480 px de large en position paysage, du moins si l'on se réfère à l'iPhone (un HTC a une résolution native de 540 x 960, un Samsung Galaxy Ace a une résolution native de 480 x 320 et un Nexus One a une résolution native de 800 x 480) : dans ce cas-là, on se place dans une optique de largeur fluide avec un maximum à définir (480 ? 640 ?) ce qui couvre toutes les possibilités (faut s'assurer que c'est viable au moins en rétrécissant jusqu'à 320 px, sachant qu'on peut aller jusqu'à 240). NOTA : Raphaël Goetter propose de prendre en compte un max de 640px (voir ici), sans doute à cause de l'iPhone.

Tout cela suppose qu'on ait défini le Viewport avec une valeur device-width constante (voir ci-dessous) pour court-circuiter le Viewport natif (de 980px sur les iPhone).

Le Viewport

Généralités

On appelle Viewport la surface affichable d'un terminal mobile. Celle-ci peut être définie grâce à un meta tag dédié nommé  viewport (au départ fourni par Apple pour Safari), de type <meta name="viewport" content="width=device-width" />. La définition du Viewport dans le <head> de vos pages HTML permet d’éviter le redimensionnement automatique de la mise en page, qui rend les contenus trop petits, de fixer la largeur du mobile et de pouvoir s’y adapter par la suite. Cette instruction court-circuite le viewport par défaut, souvent bien trop large (980px), et fournit une base commune plus proche de la réalité.

La valeur par défaut de width est 980 (valeurs comprises entre 200 et 10 000), ce qui forcera le navigateur à agir tel un navigateur standard de 980 pixels de large. La valeur par défaut de height est proportionnelle à celle de width (de 223 à 10 000). Il est possible d’utiliser device-width ou device-height à la place d’une valeur pour ajuster l’affichage plein écran de la page.

Difficultés

La gestion du Viewport d'un mobile n'est pas si aisée, comme en témoigne cette discussion initiée par Raphaël Goetter sur le site d'Alsacréations. Dans ses recommandations aux développeurs pour l'adaptation d'un site Web à l'iPad, Apple précise que les paramètres de viewport les mêmes pour iPhone et pour iPad, à condition d'utiliser la valeur constante device-width au lieu d'une valeur numérique.  

Incorrect: Using a pixel value for viewport width :

<meta name="viewport" content="width=320" /> <!--- WRONG //--->

Correct: Using a constant for viewport width :

<meta name="viewport" content="width=device-width" />

Cela permet d'ouvrir une page en pleine largeur. On peut faire la même chose avec la hauteur : 

<meta name="viewport" content="height=device-height">

Retour à l'iPhone

Par conséquent, l'iPhone 3 et l'iPhone 4 devront être traités de la même manière en considérant (merci Raphaël) que :

  • l'iPhone 3 a une largeur physique de 320 px, un device-width de 320px pour un viewport natif de 980px
  • l'iPhone 4 a une largeur physique de 640 px, un device-width de 320px pour un viewport natif de 980px

Les Media Queries

C'est l'une des puissantes innovations de CSS3, qui sert de fondement à la philosophie actuelle du Web Design Réactif (Responsive Web Design). Les Media Queries sont de nouvelles règles CSS3 qui permettent d'adapter le design d'un site web de manière conditionnelle à des résolutions d'écran données différentes. Des styles CSS différents vont alors s'appliquer à vos éléments HTML selon le type de terminal utilisé. Les Media Queries (ou requêtes de média) prolongent l'idée de feuilles de styles pour l'impression, l'écran, etc., mais cette fois-ci en spécifiant des résolutions d'écrans de manière conditionnelle. Par exemple, les requêtes de média sont utilisées pour adapter la feuille de style aux iPhone, aux téléphones Android, et autres.

Exemples

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="mini.css"/>

Cette ligne indique au navigateur d'utiliser le fichier mini.css pour les écrans de largeur inférieure ou égale à 480 pixels (ce qui est la résolution maximale de l'iPhone 3 en position paysage). Pour l'iPhone 4, on indiquerait 640px afin de cibler l'affichage de l'iPhone 4 en position portrait. Sinon, le lien est tout bonnement ignoré. Par là, on comprend qu'une media query est une expression dont la valeur est toujours vraie ou fausse.

Aussi, l'on peut jouer avec des opérations pour ajouter des conditions. Les opérateurs logiques peuvent être and "et", only "uniquement" et not "non". Pour obtenir l'équivalent du "ou", il suffit d'énumérer différentes media queries à la suite, séparées par des virgules : si l'une d'entre elles est valable, alors l'ensemble de la règle sera appliquée. Ainsi : 

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) and (resolution: 163dpi)" href="shetland.css"/>

Ou : 

@media only screen and (max-device-width:640px) and (orientation:landscape)  {
  body {
  -webkit-text-size-adjust: 70% !important;
  }
}

En outre, le nombre de requêtes n’est pas limité et ces dernières peuvent être incluses directement dans les déclarations CSS, via l’attribut @media :

@media screen and (max-device-width: 480px) {
  .column {
  float: none;
  }
}

Ou dans la commande @import, qui donne le même résultat :

@import url("mini.css") screen and (max-device-width: 480px);

Au lieu de viser une version spécifique d’un navigateur, on peut ainsi opérer des corrections chirurgicales de la mise en page pour qu’elle s’affiche au-delà de la résolution initiale.

On utilisera le plus fréquemment les media queries pour :

  • agrandir la taille du texte
  • agrandir la taille des contrôles et zones cliquables (pour une utilisation au doigt)
  • faire passer le contenu sur une seule colonne
  • masquer ou afficher des éléments spécifiques
  • ajuster les dimensions et marges

Mais aussi pour :

  • jouer sur l'orientation portrait ou paysage dans des périphériques comme l'iPad ou l'iPhone grâce à la fonctionnalité orientation, permettant de déclarer une feuille de style spécifique pour ajuster l'affichage.

Exemple :

<link rel="stylesheet" media="all and (orientation:portrait)" href="portrait.css">
<link rel="stylesheet" media="all and (orientation:landscape)" href="paysage.css">

Compatibilité

Elles sont parfaitement compatibles avec les navigateurs les plus récents, tels que Safari 3+, Chrome, Firefox 3.5+ et Opera 7+, de même que la plupart des navigateurs pour mobiles (Opera mobile et WebKit par exemple). Les versions plus anciennes de ces navigateurs ne sont bien entendu pas compatibles avec les requêtes de média. Microsoft s'est engagé à intégrer les requêtes de média dans Internet Explorer 9. Mais IE PC, IE mobile et les navigateurs Blackberry (jusqu’à os6) ne les prennent pas en compte

Toutefois, si on veut être sûr de pouvoir s'en servir dans des navigateurs anciens, on peut adopter une solution JavaScript :

  • Un plugin jQuery (2007) permet d’utiliser des fonctions de requêtes de média limitées, appliquant uniquement les propriétés largeur min et largeur max.
  • css3-mediaqueries.js, sorti plus récemment, prétend « rendre IE 5+, Firefox 1+ et Safari 2 complètement transparents et compatibles avec les requêtes de média CSS3 » intégrées par l’attribut @mediablock.

Les media queries nécessitent l’adoption d’un nouveau mode de pensée. Au lieu de laisser notre contenu de côté pour cause d’incompatibilité ou de configuration spécifique des supports, les requêtes de média nous permettent d’améliorer notre travail progressivement pour le publier sur divers supports. Mais il faut être prêt à tout re-penser autrement. Un bon exemple de stratégie de design multi-écran.

Sources : 

Conclusion : 3 approches possibles

Trois approches générales sont possibles pour la conception et la réalisation d'un site Web mobile :

  • soit détecter l’agent utilisateur et servir une version mobile dédiée, en général sur un nom de domaine dédié (version complètement différente ou juste une CSS adaptée) ;
  • soit utiliser les media-queries qui permettent d’adapter la présentation du site selon la résolution, dans une logique Responsive Web Design ;
  • soit s'en remettre à un service en ligne clef en mains comme Mobify ;

Ces dfférentes approches se retrouvent dans la mise en œuvre d'un projet Drupal. Ainsi l'on peut :

  • soit utiliser des modules comme Domain Access, Mobile Tools, Browscap pour détecter l'agent utilisateur et rediriger vers une version dédiée ;
  • soit jouer la carte du Responsive Web design et des media queries grâce au thème Omega (“Responsive HTML5 base theme”) et au module Delta associé à Context, qui sont d'ailleurs utilisés sur Acquia.com ;
  • soit utiliser le service en ligne Mobify, qui jouit d'une intégration complète avec Drupal.

À l'heure actuelle, l'approche du Responsive Web Design via les media queries est considérée comme la plus intelligente, la plus judicieuse et la plus porteuse d'avenir. Pour une petite démo intéressante, cliquez ici (redimmensionnez la fenêtre pour voir).

Exemples de script de détection d'agent utilisateur 

Premier exemple :

if (stristr($_SERVER['HTTP_USER_AGENT'], "iPhone") 
|| strpos($_SERVER['HTTP_USER_AGENT'], "iPod")
|| strpos($_SERVER['HTTP_USER_AGENT'], "Android") )
{
// ici la CSS pour les Smartphones précités ou la redirection vers la page adaptée
}
else {
// CSS classique
}

Second exemple :

if (stristr($_SERVER['HTTP_USER_AGENT'], "iPhone")
|| strpos($_SERVER['HTTP_USER_AGENT'], "iPod")) {
  header("location:/iphone/");
}

Avantages :

  • cela permet de proposer une CSS adaptée aux Smartphones, le cas échéant, une version totalement adaptée (structure et CSS),
  • qui plus est, séparer totalement les CSS destinées aux Smartphones permet une simplicité de maintenance...

Inconvénients :

  • Un script de détection ne pourra jamais détecter... que ce qu’il connaît. Il faut donc le tenir à jour !
  • L’agent utilisateur peut être changé par l’utilisateur, le script de détection peut alors être pris en défaut.

Source : OpenWeb.

PS : stratégie de contenu mobile

Une ligne éditoriale différente qui renoue avec l'essentiel

La décennie 2000 nous a appris à rendre un site compatible dans tous les navigateurs, avec la même apparence et le même contenu. Avec le Web mobile, il faut penser autrement. Un terminal mobile, c'est quelque chose que l'on emporte avec soi dans des contextes très variés dans lesquels on n'a pas besoin de la même quantité ou densité d'information. C'est pourquoi non seulement on a tendance à produire des contenus plus limités sur supports mobiles —ce qui nous permet de renouer avec l'effort de synthèse de l'essentiel face à des sites web devenus obèses — mais encore on a peut-être intérêt à proposer des contenus différents pour les terminaux mobiles, adaptés à ce contexte de mobilité et d'inconfort. Reste à voir, cependant, ce que l'adoption des tablettes va produire sur ce point, permettant peut-être d'avoir tous les avantages du Web mobile (légèreté, ubiquité) et du Web de bureau (intégralité des contenus et fonctionnalités).

Quelques principes à respecter 

  • Peu de contenu par page (lenteur au chargement sinon + inconfort de consultation pour l'usager)
  • Contenu fractionné en portion logique et bien délimité
  • Présentation de lien sous forme de bouton facile à cliquer
  • Texte en caractères larges et lisibles
  • Limitation de la manipulation de la page par l’utilisateur (scrolling horizontal, zoom)
  • Prise en compte des avantages et contraintes de la navigation tactile
  • Simplicité du contenu
  • Pas de plug-in additionnels de type Flash
  • Taille des pages et des images réduites et optimisées
  • Oublier les effets de survol

Liens

[ work in progress, merci de votre indulgence et de vos contributions ]

 

Comments

Merci pour cette riche et agréable synthèse, de quoi continuer mes recherches.

super, merci pour toutes ces infos qui me font gagner un temps fou !

L'utilisation de Jquery mobile permet de respecter bon nombre de principes énumérés ici

par expérience j'encourage tt le monde à utiliser jquery mobile. il prend en considération bcp de contraintes mentionnées ci dessus

Bonjour

Merci pour cet article qui 'est très intéressant. Je crois qu'il faut évoluer avec l’évolution des technologies mobiles, dorénavant il est nécessaire d'avoir un site web pour mobile, surtout si on a une entreprise qui veut rester en communications avec ses clients et les mobinautes en général.

Martin

Lektum's picture
Lektum