Une version spéciale Smartphone et plus largement handheld (petit écran) est une étape qui peut être compliquée à envisager. Heureusement, les standards du Web offrent quelques armes fort bienvenues et efficaces pour la franchir. Après tout, présenter un site en 480*320 pixels n’est jamais... qu’un style alternatif.

Si votre structure XHTML est suffisamment robuste - je vous invite à (re)lire avoir plusieurs présentations alternatives -, préparer et développer une version Smartphone pour votre site sera d’autant plus aisé. Néanmoins, quelques écueils techniques peuvent se présenter... et le facteur temps peut vous obliger à faire quelques choix.

Voyons quelques points afin de comprendre les tenants et les aboutissants de la création d’une version Smartphone !

Attention : cet article traite uniquement de l’adaptation d’un design à une version pour Smartphone, et non de développement de sites totalement dédiés aux mobiles. Les techniques qu’il aborde sont à replacer et à garder uniquement dans le cadre d’une adaptation aux Smartphones.

Quelques informations et bons réflexes

Principales recommandations :

Qui peut le plus peut le moins : préparer un site pour les Smartphones sera d’autant plus facile si vous avez déjà bien travaillé sur votre site et les démarches qualité propres aux sites internet (réduction du poids des pages, CSS et images optimisées, diminution des requêtes HTTP, séparation structure/présentation, ordre logique de votre structure, etc.).

Il faut avoir à l’esprit que surfer sur un Smartphone n’est pas seulement une question de résolution plus petite : la connexion est moins performante et souvent plus onéreuse que sur un PC connecté à un réseau. Un site par exemple trop lourd ou trop long à charger peut se disqualifier d’entrée de jeu.

Si certaines bonnes pratiques ne sont pas indispensables pour une version Smartphone, d’autres sont tout bonnement incontournables :

• UTF-8 est le jeu de caractères incontournable du Web, le validateur mobile du W3C vous le dira et vous le répétera !
• Une structure robuste, logique est plus que jamais indispensable afin de donner de la souplesse à vos CSS.
• Vos pages, vos images et vos CSS doivent être aussi optimisées et légères que possible... et si ces mêmes pages et CSS sont bien conçues (bonne utilisation des sélecteurs, décomposition logique des différentes parties, propriétés factorisées, etc.), l’optimisation n’en sera que plus efficace.
• Dans le cas d’un site ayant un très fort trafic, vous pouvez également penser à minifier vos fichiers CSS, Javascript, et même votre structure.
• Activer la compression GZIP ou DEFLATE sur vos pages permettra de bien réduire le poids de vos sites après les avoir optimisés.
• Penser à mettre en cache vos contenus est une bonne habitude à prendre... particulièrement si votre site doit être consulté en situation de mobilité. Pour ces deux derniers points, je vous invite à lire compression des pages via GZIP ou Deflate et mise en cache des contenus.

Plus généralement, pensez "petit écran" et "navigation tactile" :

• Certains événements Javascript n’ont pas de sens sur un Smartphone : par exemple Mouseover et Mousemove ne réagissent pas car le mouvement du doigt sur l’écran fait défiler la page, Doubleclick ne se déclenche pas... tapoter deux fois déclenche en général un zoom.
• Le flash est à oublier pour de nombreux Smartphones, notamment l’iPhone qui ne l’affiche tout simplement pas. Idem pour le Java.
• Pensez également à afficher des caractères larges et lisibles... même si l’écran est petit, les caractères ne doivent pas l’être trop !
• L’affichage multi-colonnes est à proscrire, les flottants sont à afficher empilés et non plus côte à côte par exemple.

C’est là que la structure de votre document va être mise à l’épreuve : par exemple, l’ordre naturel de navigation devra être correct en empilant les blocs auparavant positionnés comme flottants.

Le W3C a édité les bonnes pratiques du Web mobile en Flipcards, c’est un excellent résumé du guide complet des Pratiques exemplaires du Web mobile 1.0.

Toujours sur le même sujet, le Validateur W3C Mobile a été récemment amélioré et donne de bons conseils. Cela peut être une étape très intéressante dans la conception ou tout simplement pour l’apprentissage.

Attention : encore une fois, le validateur mobile est là pour tester les sites spécialement dédiés aux mobiles (et pas uniquement adaptés et/ou dédiés aux Smartphones). Ses critères sont donc très durs à atteindre pour une simple adaptation Smartphone et sont à relativiser.

Quelques informations et points de repère :

• La résolution native pour surfer sur un iPhone/Ipod touch version 3 est de 320*480 pixels (assez similaire pour d’autres Smartphones) en portrait, et 480*320 pixels en paysage.
• L’iPhone version 4 quant à lui a une résolution légèrement supérieure (max-width de 640 px).
• Safari, Firefox, Opéra, Chrome et Android gèrent les media-queries,
• IE PC, IE mobile et les navigateurs Blackberry (jusqu’à os6) quant à eux ne les prennent pas en compte,
• On peut préciser à Firefox, Chrome, Safari, Safari Mobile, Android, Opera Mini, Opera Mobile, Firefox mobile (Fennec) de s’adapter aux résolutions via le méta viewport : < meta name="viewport" content="width=device-width, height=device-height" />
• Opera ainsi qu’Opera mini acceptent aussi le média handheld, activable via le mode de rendu petit écran. Ce qui d’ailleurs surclasse les CSS screen s’il est activé.

Plusieurs approches dans l’adaptation d’un site pour les Smartphones sont envisageables, cela peut aller d’une très légère adaptation (à moindre frais) à une adaptation complète... en passant par une version hybride. Tout dépend des navigateurs ciblés et du temps consacrable à cette adaptation.

1) Pour les sites pouvant d’entrée de jeu s’adapter à des résolutions plus basses à moindre effort, nécessitant une adaptation mineure des contenus

a) Document trivial supportant un design élastique

Dans ce cas, la version pour les médias screen et handheld sont les mêmes, sans aucune ou très peu d’adaptations.

Avantages :

• il n’y a pas de problème pour les hautes résolutions et pas de souci pour les basses résolutions,
• une seule CSS pour tous les médias et des ajustements mineurs très rapides à mettre en œuvre feront l’affaire.

Inconvénients :

• nous parlons bien ici d’un design trivial sur un simple document... le cas est rare,
• pour le cas d’un design non trivial, imaginer un design qui fonctionne aussi bien en 1440*900 qu’en 480*320 n’est pas une chose aisée... ou même tout simplement possible.

Conclusion : ce cas parfait est rarissime ou extrêmement dur à concevoir... hormis sur un design trivial.

b) Un site avec une résolution plutôt basse, peu d’éléments de contenu et de mise en page :

Adapter rapidement ce genre de site ne demande que très peu d’efforts, il restera consultable sur un Smartphone avec la même CSS que celles destinée au média screen... toutefois sans être parfait.

Avantages :

• une même CSS pour les médias screen et handheld, le tout combiné au meta viewport permettront d’obtenir un résultat satisfaisant sur les Smartphones,
• le temps d’adaptation peut être extrêmement court, quelques simples tests et ajustements suffisent.

Inconvénients :

• si le 800*600 est déjà en passe de disparaître, les sites ayant une résolution inférieure avec peu d’éléments de contenu et une mise en page simple le sont encore plus... ce cas plutôt facile est plutôt rare.
• attention aux petites images : elles risquent d’être minuscules sur un petit écran. Privilégiez des éléments textuels pour que l’utilisabilité et la lisibilité restent correctes. Vérifiez également que vos tailles de polices sont correctement lisibles.

Conclusion : à l’instar du cas précédent, ce cas, qui peut être très facile et rapide à adapter... est relativement rare.

Pour les sites ayant une résolution de base plus élevée et/ou nécessitant une adaptation plus poussée des contenus

Deux approches sont envisageables :

• détecter l’agent utilisateur et servir une version spéciale : soit une version complètement différente (structure, contenu et CSS) soit juste une CSS adaptée,
• utiliser les media-queries qui permettent d’adapter la présentation du site selon la résolution.

Ces approches ont chacune leurs points forts et leurs inconvénients, voyons la première.

1) Mettre côté serveur un script de détection de l’agent utilisateur qui redirige vers une version adaptée :

Il peut être tout à fait envisageable de servir une version totalement différente et/ou adaptée en cas de forte demande. Exemple : les sites communautaires proposent des versions très bien adaptées à la navigation Smartphone (contenu léger, etc.)... et à leur fréquentation plutôt forte.

Idéalement, l’idée est de charger uniquement une autre CSS, comme pour un style alternatif : cela évite de redévelopper complètement la structure du site.

Un exemple de détection de l’agent utilisateur via PHP :

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 
}

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...
• ... et cela permet de proposer la CSS prévue pour les Smartphones en prime pour le média handheld,
• cela permet également de conserver un style-switcher et/ou les CSS alternatives pour peu que votre site en utilise.

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.
• Dans le cas où le site est totalement réécrit (pas uniquement sa CSS), deux versions complètes du site (structure et CSS) sont à maintenir.

Conclusion : cette solution est la solution la plus "passe-partout", de nombreux sites l’utilisent et proposent même une version Smartphone totalement dédiée (structure et CSS). Elle permet de s’en sortir si le site n’a pas été initialement développé pour supporter une version Smartphone uniquement adaptée via CSS (version trop lourde, ou trop gourmande). Cette solution est également efficace dans les besoins très particuliers (fonctionnalités comme la géolocalisation) : là une version totalement adaptée voir une application native est préférable.

Seul souci, le redéveloppement de la structure et de la présentation (voir d’une application native) a un coût non négligeable.

2) Utiliser les media-queries de CSS 3 :

Les media-queries sont une nouveauté introduite par CSS 3, elles sont déjà implémentées par bon nombre de moteurs de rendu : Webkit (Safari, Chrome), Presto (Opera) et Gecko (Firefox) étant les principaux.
Le principe de fonctionnement bien que très puissant en est simple :
les media-queries permettent d’appliquer des styles selon les paramètres du media (résolution, etc.).
Plutôt qu’un long discours, un exemple de déclaration parlera de lui-même :

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

ou via

@media screen and (max-device-width:480px) {
/** ici les styles qui vont bien **/
}

Notre CSS "style_mini.css" sera donc appliqué si le média est de type screen et si sa largeur maximale est de 480 pixels.

Voici deux exemples visuellement très efficaces :

• Démo media-query (via Daniel Glazman),
• Démo de media-query sur A List Apart

Un autre exemple moins impressionnant, mais plus simple : une démo simple de media-query

(Pensez à redimensionner les fenêtres pour voir les changements)

Concernant le dernier exemple, nous pouvons voir que si la résolution passe en-dessous de 480px :

• les propriétés de normal.css et little.css s’additionnent pour #titre,
• par contre, les propriétés définies pour body,html définies dans little.css vont "écraser" celles de normal.css

Avantages :

• cela permet d’éviter la case "script de détection" et ses limitations intrinsèques,
• plusieurs résolutions sont prévisibles : en général, pour le média screen ordinateur (1024px) et le screen Smartphone (maximum 480px), et éventuellement une version extrêmement épurée pour les toutes petites résolutions/connexions,
• on évite aussi au passage de redévelopper l’intégralité de la CSS principale, on adapte juste cette CSS à une résolution donnée (faire disparaître un bloc, fixer une taille pour un conteneur, etc.).

Inconvénients :

• votre structure va être mise à l’épreuve, car au moins deux CSS vont se baser dessus (plus une autre CSS si l’on prend en compte la version imprimable),
• Internet Explorer ne supporte pas du tout les media-queries (version mobile et 8 comprises),
• les propriétés de la CSS spéciale Smartphone vont surcharger celle de la version screen dans le cas où la media-query est appelée, cela peut devenir extrêmement compliqué si votre site a plusieurs styles alternatifs,
• quelques curiosités peuvent survenir sur Safari mobile avec des media-queries sur des CSS dites "favorites" (les CSS déclarées avec un attribut title).

Si les concepts de CSS favorites ou persistantes ne vous disent rien, vous pouvez aller lire Avoir plusieurs présentations alternatives.

Exemple :

 < link rel="stylesheet" 
    type="text/css" 
    href="style.css" 
    title="default" 
    media="screen" />
 < link rel="stylesheet" 
    type="text/css" 
    href="style_mini.css" 
    title="Mini" 
    media="screen and (max-width: 480px)" />

Si la CSS principale et celle en media-query ont un attribut title différent, des bugs curieux peuvent se manifester. Autant éviter de spécifier un attribut title dans vos déclarations et ainsi préférer les CSS dites persistantes (sans attribut title), en précisant bien évidemment le média :

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

Une bonne idée à retenir : il est possible d’intégrer le contenu via :

@media screen and (max-device-width:480px) {
// ici les propriétés 
}

Et ce directement dans la CSS prévue pour le 1024*768, cela évite d’avoir une profusion de fichiers CSS.
Par contre, cela implique une double série de tests à chaque modification dans cette feuille de style.

Conclusion : cette solution permet de garder la structure existante du site sans la redévelopper et même une partie de sa présentation. Typiquement, un site développé via les principes des standards peut être adapté rapidement et efficacement ainsi. Seule contrepartie, votre structure devra être très bien étudiée pour utiliser les media-queries. :)

Conclusion

Comme nous avons pu le voir, plusieurs méthodes et plusieurs vitesses sont possibles dans l’adaptation d’un site pour les Smartphones, à vous de voir lesquelles choisir selon votre projet et ses contraintes.

Sans aucun doute, les standards du Web ont de solides arguments et permettent d’envisager cette nouvelle étape avec une certaine sérénité.

Références et liens :

• Avoir plusieurs présentations alternatives
• La qualité s’impose sur le Web
• Changer de jeu de caractères pour UTF-8
• Compression des pages via GZIP ou Deflate et mise en cache des contenus
• Un script de détection de l’agent-utilisateur très complet
• Validateur W3c Mobile
• Flipcards sur les Bonnes Pratiques du Web Mobile du W3C
• W3C : Pratiques exemplaires du Web mobile 1.0
• Mobile compatibility tables