Adapter un site pour les Smartphones

Openweb.eu.org > Articles  > Adapter un site pour les Smartphones

Abstract

Avec la démocratisation des Smartphones, il devient nécessaire de penser en concevant un site à sa version sur petit écran... voyons donc quelles peuvent être les approches pour adapter un site sur ce nouveau support et en quoi les standards peuvent grandement faciliter cette adaptation.

Article

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 :

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. sourire

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 :

À propos de cet article

  • Openweb.eu.org
  • Profil : Expert
  • Technologie : (X)HTML, CSS
  • Thème : Mise en page
  • Auteur :
  • Publié le :
  • Mise à jour : 29 janvier 2012
  • 14 commentaires

Vos commentaires

  • Marco Le 1er octobre 2010 à 14:42

    Bonjour,

    merci pour l’article, très intéressant.
    Juste une remarque : dans les inconvénients des media queries, vous écrivez :
    * 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,

    Ma remarque : pour éviter cela, n’est il pas simplement possible d’utiliser un seconde media query pour n’appliquer une autre feuille de style qu’au media ayant une résolution supérieure à... ?

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

  • Frank Taillandier Le 3 octobre 2010 à 11:30

    Il est encore courant de penser mobile en fin de chaîne. Il serait plus logique si on a décidé de développer une version mobile de la penser dès le début avant même la version desktop. Cela oblige à se concentrer sur l’essentiel - fonctionnalités, design, performance, accessibilité - et de proposer une version mobile qui utilise toutes les spécificités du mobile et non une version dégradée d’un site desktop.

  • Nicolas Chevallier Le 14 octobre 2010 à 08:50

    @Franck Taillandier : le problème c’est que l’arrivée des smartphones a été brutale. Ce n’est que depuis la sortie de l’iPhone que créer une version adaptée aux mobiles est devenue "rentable". Le problème c’est qu’il y a de plus en plus de terminaux à gérer avec des tailles différents et des interfaces différentes (aujourd’hui l’iPad, et demain ?). On converge vers deux types d’utilisation ? tactile ou non. Et pourtant déjà les constructeurs annoncent des interfaces 3D, ... Encore un travail d’adaptation.

    Pourquoi ne pas partir du terminal le plus basique et développer pour ce terminal, en adaptant ensuite pour les autres ?

    Nicolas Chevallier

  • Nicolas Le 1er novembre 2010 à 09:31 En réponse à : Frank Taillandier

    C’est évident, si on y pense d’entrée de jeu, le concevoir est plus simple. Reste le cas du site qui existe déjà et qu’il faut "mobilifier" si j’ose dire. sourire

  • Anonyme Le 8 novembre 2010 à 16:03

    J’essaye de me lancer depuis quelques temps et je n’y arrive pas vraiment , mais vos conseils vont m’être d’une précieuse aide

    poker gratuit
    Meilleure salle de poker

  • Nicolas Hoffmann Le 12 décembre 2010 à 00:58 En réponse à : Nicolas Chevallier

    Le gros problème, si je prends ce raisonnement d’un point de vue pragmatique... c’est que le client demande rarement de partir d’un terminal basique pour imaginer son site.

    Si l’idée de partir de la version smartphone est intéressante et est du bon sens, en pratique, il est difficile de commencer par là avec un client : déjà l’investissement n’est pas toujours jugé rentable (et parfois à juste titre : le client n’a pas nécessairement un budget pour cela), et il reste que le client a du mal avec une version minimaliste... ou ne serait-ce que simplifiée.

    C’est là à mon sens que les professionnels doivent entrer en jeu, à mon avis, il faut avoir à l’esprit une version smartphone en travaillant une version "classique" d’un site. Et reste aussi à développer des outils et une pratique qui permet d’envisager une version smartphone pour un coût très léger, ce qui incitera le client à tenter.

    Pour cela, je reconnais que la version simplifiée via media-query a de bons arguments : il est possible de pondre une version smartphone en quelques heures via cette méthode.

  • Alexandre Chombeau Le 18 janvier 2011 à 14:46 En réponse à : Marco

    Bonjour à tous,

    J’ai écris un article sur l’utilité d’un site internet optimisé pour smartphone, si cela vous intéresse : http://www.creation-site-vitrine.fr/site-internet-smartphone

    Cordialement

    Alexandre Chombeau

  • jeanjean Le 1er novembre 2011 à 05:20 En réponse à : Anonyme

    J’ai trouvé un tuto sur l’adaptation d’un site pour iPhone. C’est une technique en CSS qui n’impose pas de modifier le code source du site.

    http://blog.evolya.fr/index.php?post/11/10/2011/Adapter-un-site-web-pour-les-peripheriques-mobiles-grace-aux-CSS

  • Anonyme Le 26 décembre 2011 à 18:11

    Article toujours d’actualité et intéressant. Il est vrai que dans certains cas, déporter et adapter l’ensemble des fonctionnalités d’un site sur un terminal mobile peut-être impossible de par la taille réduite de l’écran. Mais le problème de fond est de repenser les fonctionnalités que l’on propose. On devrait repenser à la Loi 80/20 de Pareto et ne retenir que les 20% fonctionnalités les plus importantes ou comme disait Steeve Jobs il me semble : la perfection n’est pas quand il n’y a plus rien à ajouter mais quand il n’y a plus rien à enlever.

    Gilles Gallico

  • Vivien Le 3 janvier 2012 à 16:46

    Bonjour,
    J’ai déjà lu quelques articles sur le fait d’adapter un site pour le mobile et votre façon d’aborder la chose la rend encore plus sympathique. J’ai déjà fait l’essai des media queries et à ma grande surprise elles sont supportées par l’ensemble des navigateurs modernes et sont très fiable.
    J’avoue que depuis quelques temps, je ne peux plus m’en passer.
    En revanche j’ai quelques réticences à utiliser le javascript pour ce genre de choses.

    Vivien Blasquez

  • Ludovic Le 28 février 2012 à 10:11

    Le problème avec les médias query c’est que les smartphones ont de plus en plus tendance à avoir des résolutions hautes (fort semblable au petit pc portable.). Je pense qu’une meilleure solution est d’utiliser une détection par programmation qu’il faut par contre régulièrement mettre à jour. Et surtout ne pas oublier de basculer vers la version "classique" car les tablettes risquent d’être considérées comme des smartphones ce qui n’est pas le bon plan.

    Pour les pages web il faut penser à un système progressif, il est préférable que le GSM sache afficher la page (même très très moche) et ensuite rajouter couche par couche (CSS, JavaScript, etc.) plus le navigateur est "puissant" et "récent" plus la page web sera agréable à utiliser.

    Toute une histoire pour réussir nos chers GSM...

    Ludovic Evrard

  • Julie Le 6 septembre 2012 à 10:04

    Merci pour toutes ces informations utiles. Il va vraiment falloir que je me motive à intégrer tout ça pour mon blog.

  • jaocuh Le 12 avril 2013 à 13:13

    Merci pour votre partage de connaissance. Enfin j’ai compris pourquoi notre site ne peut être navigué sur les Smartphones.

    Il y a du travail pour l’adaptation...

  • GRANDE DANIEL Le 4 décembre 2014 à 15:35

    Merci pour tous ces renseignements et commentaires... je vous quitte, j’ai du boulot sur l’écran !!!

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom