Le Web mobile est un environnement de développement en plein essors et nécessite une attention particulière de par les contraintes qu’il impose.
Penser responsive est un bon début pour rendre l’expérience utilisateur accessible sur tout support, mais peu encore se soucient du temps de chargement qui fait voler en éclats le rapport coûts/bénéfices d’une intégration adaptative.
Voir la démo Télécharger la source
La dégradation progressive en première réponse au responsive
La première vague de designers qui ont répondu à la portabilité de leurs œuvres s’est ruée vers une solution facile qui était la dégradation progressive. Elle consiste en supprimer les effets et éléments moins essentiels d’une page en fonction de résolutions décroissantes.
Cette solution royale pour des designs déjà accessibles sur bureaux ne demande que de rétablir les largeurs en pourcentage, et de modifier quelques valeurs ou propriétés CSS pour laisser le tout s’adapter au support de l’utilisateur, comme ci-contre :
article { float: left; width: 31.25%; margin: 1.0416666666%; } /* 3 colonnes(proportions de 960.gs) */
@media screen and (max-device-width: 640px),
@media screen and (max-width: 640px) {
article { width: 47.9166666666%; } /* on passe à 2 colonnes */
}
@media screen and (max-device-width: 320px),
@media screen and (max-width: 320px) {
article { float: none; width: auto; } /* on passe à 1 colonne */
}Quelques exemples : www.juslisen.com, 10k.aneventapart.com, webdesignerwall.com.
(Bien entendu, je n’évoque ici que l’adaptation du design, et non du contenu en lui-même, qui soulève bien d’autres problèmes qu’un débat a tenté de résoudre ici même).
Comme le souligne Luke Wroblewski dans son ouvrage Mobile First chez A Book Apart, la navigation sur mobile croît sans cesse, au point qu’on peut espérer dépasser le milliard d’internautes mobiles d’ici à 2013. La priorité leur revient due aux performances limitées de leurs smartphones, et à ce jour, comme après chaque découverte, nous sommes à l’étape d’optimisation et de démocratisation des avancées.
L’amélioration progressive en réponse au temps de chargement
Lorsque vous appliquez la dégradation progressive, vous ne donnez pas moins de travail au navigateur mobile. En fait, vous lui en rajoutez, d’autant de « couches » que vous superposez. Le CSS est d’abord interprété comme pour un affichage bureau, pour ensuite, étape par étape, apporter des correctifs et rendre l’affichage adapté au mobile. Le bilan est lourd, une feuille complète et 2 ou 3 quarts de feuilles ont étés interprétés successivement.
L’idée est alors de penser d’abord à l’interface mobile, puis d’apporter à chaque palier de résolution une valeur ajoutée à l’expérience utilisateur, traduite par une réorganisation des éléments, l’apparition de contenus moins essentiels, une division du contenu en colonnes etc.
Avec quelques media-queries à notre secours, on parvient à quelque chose du genre
article { margin: 1.0416666666%; } /* 1 colonne */
@media screen and (min-width: 320px) {
article { float: left; width: 47.9166666666%; } /* on passe à 2 colonnes */
}
@media screen and (min-width: 640px) {
article { width: 31.25%; } /* on passe à 3 colonnes */
}Chaque support ne chargera que ce qui lui est destiné. Un mobile, pourvu d’un piètre processeur, ne devra alors interpréter qu’une infime partie du CSS. La tablette, un peu plus performante, appliquera sans rouspéter la couche supplémentaire qui lui est destinée, et ainsi de suite.
Nous avons donc offert ainsi la solution optimale répondant à chaque palier de besoin.
Notions à prendre en compte : un peu de bon sens
Il manque encore quelques précisions pragmatiques pour savoir assigner de manière pertinente le CSS efficace à vos éléments. Quelque chose qu’on oublie aisément lorsqu’on dégrade, c’est de supprimer les pseudo-éléments :hover pour les mobiles et tablettes pour la simple et bonne raison qu’ils ne sont pas visibles.
En amélioration, ces éléments seront donc à placer sur le format bureau de votre design, et non à l’origine, sur mobile ; à noter que c’est d’autant plus primordial si vous utilisez des transitions/transformations :
a.social { display: block; width: 30px; height: 30px; /*...*/ }
@media screen and (min-width: 640px) {
a.social { transition: all 0.3s ease; }
a.social:hover { transform: rotate(30deg) scale(0.9); }
}
Les transformations ne seront pas chargées sur mobile
Enfin, une question que beaucoup se posent sûrement, c’est de savoir quelles sont les largeurs à partir desquelles on « passe au palier supérieur ».
Je vois apparaître beaucoup de résolutions d’appareils dans les medias-queries, et personnellement, je pense que ça n’a pas de sens. Vous ne faites pas un site de 1024 pixels pour un écran de 1024 pixels de large ? Pourquoi faire un design de 480 ou 640 pixels ?
Commencez par analyser vos besoins avant de figer vos paliers. Définissez un seuil de clarté à partir duquel l’ajustement fluide ne suffit plus, à partir duquel vous réorganiserez vos éléments ; celui-là même qui donnera sa valeur au min-width de votre media-query. Vous aurez alors quelque chose de cohérent et de pertinent, plutôt que de vous contraindre à penser aux résolutions d’écrans, qui changent de mobile en mobile.
Pour illustrer mes propos, je vous ai concocté une maquette. Je définis mes paliers de lisibilité en fonction de la taille de l’image. Lorsque j’ai 2 colonnes, je dis qu’elles sont appréciables de 200 pixels à 300 pixels (largeur maximale de l’image), ce qui correspond à un palier de 418 pixels à 626 pixels. Je vous invite à lire les commentaires de la feuille de styles pour le détail des calculs. Afin de vous rendre compte, le mieux est que vous testiez par vous-même en ajustant la taille de votre navigateur :
Voir la démo Télécharger la source
Conclusion
La première étape pour penser mobile, c’est penser optimisation des performances.
L’amélioration progressive est une solution qui demande d’inverser l’ordre des priorités et d’être assez flexible pour penser d’abord au petit écran, mais permettant d’alléger de beaucoup l’interprétation de vos feuilles de styles sur nos pauvres petits smartphones surmenés par notre avidité technologique. Ce n’est là, bien sûr, qu’un pas vers l’optimisation globale d’un site web pour mobiles, mais qui mérite son attention. J’aimerais enfin mentionner l’article de Raphaël Goetter sur le sujet qui complète ce qu’il y a à dire sur l’optimisation des CSS.
Merci à vous qui m’avez lu jusque là, à Matthieu Bué pour sa patiente contribution, et à l’équipe du WDFR pour m’offrir cet auditoire.
(Les images sont tirées du jeu Rayman Origins, empruntées à jeuxvideo.com)



Pingback: Mobile | Pearltrees
Pingback: Revue du web 1 : news pour les webmasters | Blog Codeur.com
Pingback: Design mobile : différencier web et application ? » Webdesign Friday (#wdfr)
Pingback: Template gratuit d'un site au webdesign responsive en single page
Pingback: Introduction à la performance pour le Web mobile » Webdesign Friday (#wdfr)
Pingback: [Dossier] Comment créer un site web moderne tourné vers le futur ? | Webcercle
Pingback: Responsive design, la conception adaptative d’un site web | Blog de l'agence Oréalys
Pingback: Web mobile : introduction et glossaire Montserrat Agence de Communication
Pingback: T42 : le projet qui a pour ambition de faire évoluer le web | PUShAUNE
Pingback: Le « Responsive Web Design », quésako ? › Jérémy Barbet › Web & UI Designer
Pingback: Methodology in Mobile First | Creative Technologist Reference
Pingback: iiiprove List
Pingback: skachat turbo
Pingback: skachat gprs
Pingback: skachat vechera
Pingback: skachat krysu
Pingback: Adela (d3kk1) | Pearltrees
Pingback: Site Inspiration | Pearltrees
Pingback: projet | Pearltrees