Responsive design pour ou contre

[zeb]

J'ai eu le plaisir de lire un article que j'estime assez bon sur la problématique des sites pour mobile.
François-Olivier y expose son point de vu a la lumière de son expérience perso en abordant deux concepts proches des sites mobiles, savoir la conception et le référencement. Bien que l'article soit orienté SEO il a su introduire quelques concepts de base qui impactent la conception technique.
Merci a lui pour cet article pour commencer, ensuite j'aimerai avoir les avis de ceux qui se sont lancé dans cette aventure (j'y pense moi même c'est pas pour rien que j'ouvre ce sujet).

Ma "grande question" porte sur le responsive design, mon avis est qu'il n'est pas forcement la solution idéale. D'une part il est très difficile de garantir un affichage optimisé pour des écrans fondamentalement différents, et ensuite je pense que pas mal de données n'ont pas forcement leur place sur une page "mobile".

Bref a mon avis une page classique destinée a un écran classique n'est vraiment pas adaptée a un mobile et ceci même si le CSS "mobile" permet de l'alléger visuellement tout en la rendant compatible avec une navigation mobile.

Ma question subsidiaire porte sur les "NDD mobile". Je pense m'orienter vers une solution sous domaine pour mobile. Avez vous des retours d'expérience a partager dans ce contexte ?

 

[patapon87]

Je ne peux que te donner mon experience :

J'ai bossé sur la conception de sites en responsive design : c'est vrai que c'est pas mal. Ca demande du boulot mais au moins c'est "clair".
Sur le côté "toutes les données n'ont pas forcément leur place sur un site mobile" pourquoi tu ne les ferai pas disparaitre avec le responsive ? C'est possible

 

[zeb]

Oui le display none est une solution mais elle ne vas pas dans le sens de na pas transmettre les données de plus ce qui me dérange c'est qu'implanter des conditions pour écarter des "datas au cas ou" dans le code ne me semble pas propre.

 

[spout]

Je suis pour mais je dirais qu'il faut faire les 2, détection du UA mobile côté serveur (afin d'adapter les images par exemple) + media queries.

 

[zeb]

afin d'adapter les images par exemple

c'est dans ce sens (entre autre) que je m'oriente progressivement vers un sous domaine distinct qui aurait son propre code. Je souhaite non seulement que le site soit plus light a charger tant d'un point de vue image que système de navigation etc ...
Il y a aussi la problématique de monétisation qui est distincte.

 

[JanoLapin]

il faut aussi deux autres conditions: du fluid grid design, et des éléments (images, mais pas seulement) exprimés uniquement en valeur relative.

 

[1eB]

Oui le display none est une solution mais elle ne vas pas dans le sens de na pas transmettre les données de plus ce qui me dérange c'est qu'implanter des conditions pour écarter des "datas au cas ou" dans le code ne me semble pas propre.

Si on utilise un display none c'est que l'information n'est pas utile, si elle ne l'ai pas c'est qu'elle n'a pas sa place sur la page, même pour un affichage non-mobile.

«La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.»

Pour moi, le responsive design, c'est ce que son nom indique, simplement adapter la mise en page du contenu en fonction de l'écran sur lequel il va être lu.
Sur un smartphone on évitera les menus horizontaux, les colonnes et les marges épaisses, limiter à un scroll vertical.
Alors que sur grand écran on va aérer le texte, disposer de façon a afficher le plus d'information sans avoir besoin de scroller.
On va aussi jouer sur le dimensionnement des images.
Les images peuvent être sélectionnées via CSS pour éviter les détections serveurs.

Cela demande beaucoup plus de travail au niveau CSS mais un seul travail rédactionnel.
De plus ça ne fait qu'un seul site à maintenir et évite le code dupliqué et les évolutions en décalage.

Sinon il faut refaire un travail de rédaction pour le site mobile (surtout s'il est placé sous un sous domaine) et cela réparti le référencement sur ces domaines ce qui est dommage.

 

[WebRankInfo]

ne faut-il pas distinguer plusieurs cas de figure ? si l'information à transmettre, ou l'offre disponible, doit être limitée sur la version mobile, alors autant faire un site à part. le site mobile n'aura pas autant de fonctionnalités et de contenus que le site ordi, mais au moins il sera très adapté au mobile
dans les autres cas, le responsive me semble le plus adapté

 

[fredfan]

Il faut se méfier de l'idée qu'un utilisateur mobile veuille moins d'information qu'un utilisateur sédentaire. Il m'arrive souvent de commencer à lire un article sur le pc et de le finir sur la tablette ou le smartphone. Ca ne veut pas dire que je me retrouve tout à coup dans le métro, pressé, ou que mes centres d'intérêt changent. C'est un peu agaçant de se retrouver dans un autre monde. Surtout sur la tablette qu'on oriente d'autorité sur le site mobile, alors qu'on a la même résolution que sur un pc portable qui sera orienté sur le site sédentaire. A part des menus redondants, il vaudrait mieux éviter d'enlever trop de choses pour l'affichage mobile

Quant à la séparation site mobile/site pc, elle ne résout pas la variété énorme de cas de figures. Orientation de l'écran, résolutions, etc... Et il y aura des cas de plus en plus variés quand d'autres supports apparaitront. Est-ce qu'il ne vaut pas mieux carrément tout gérer sur un seul css ?

 

[Leonick]

il ne faut pas oublier qu'au niveau navigation, entre une souris et un doigt, on n'a pas la même sensibilité. Donc pas évident d'utiliser le même type de navigation

 

[HawkEye]

L'info peut rester tout aussi disponible sur une version mobile. C'est avant tout une question de navigation.
Sur la plupart des sites que je monte en incluant une version mobile, le client opte pour un contenu allégé. Tout reste en fait disponible, mais la navigation se fait via un menu plus léger, ainsi que par la recherche

 

[zeb]

Si on utilise un display none c'est que l'information n'est pas utile, si elle ne l'ai pas c'est qu'elle n'a pas sa place sur la page, ...

C'est un peut brut de décoffrage comme argument et surtout un gros raccourci. Les format publicitaire et ou régie que tu va utiliser en mobile ou fixe ne seront pas forcement les mêmes, le display none n'est pas une solution dans ce cas (d'ou a ce moment la necessité de mettre des conditions dans le code et là ... bonjour la lourdeur et la maintenance). Mais tu peut très bien avoir une redondance des éléments de navigation pour des raisons pratiques (pages très importantes par exemple) que tu ne souhaite pas forcement proposer sur une version mobile. Bref c'est pas aussi "simple" pour s'en remettre exclusivement a du "display none" pour s'adapter.

Sur un smartphone on évitera les menus horizontaux, les colonnes et les marges épaisses, limiter à un scroll vertical.
Alors que sur grand écran on va aérer le texte, disposer de façon a afficher le plus d'information sans avoir besoin de scroller.
On va aussi jouer sur le dimensionnement des images.

Oui là je partage ton avis pour ces remarques c'est en effet logique vue la linéarité de l'écran. Seulement le site qui a justement un menu horizontal qui ne peut pas forcement passer en mode vertical avec CSS là il y a un os.

De plus ça ne fait qu'un seul site à maintenir et évite le code dupliqué et les évolutions en décalage.Sinon il faut refaire un travail de rédaction pour le site mobile (surtout s'il est placé sous un sous domaine) et cela réparti le référencement sur ces domaines ce qui est dommage.

Ça c'est pas un souci pour moi, c'est d'ailleurs pour ça que je me pose toutes ces questions.

Faire un nouveau site donc physiquement ajouter un domaine sur le serveur c'est ajouter un dossier template, un dossier widget dans le CMS (donc une trentaine de fichiers) et ajouter 30 lignes dans le fichier de config du CMS. Éventuellement (mais c'est pas obligatoire) Créer une base de données et y installer les contenu voulus, mais dans ce cas de figure (site mobile), taper directement dans la même base de données que le site PC donc vraiment pas chiant avec l'opportunité de faire 100% mobile. Pour le côté maintenance, tu l'a compris je modifie un site tous les sites sont impactés ... Bref la maintenance c'est a l'échelle serveur donc pas trop chiant (déjà qu'a la base sur du code propriétaire c'est carrément plus léger).

Le côté ref en revanche oui c'est évident mais comme quand tu fait du multilingue ... Bref il y a l'avantage de l’inconvénient si tu as deux domaines a référencer tu as aussi plus de pages indexées ... (pour le moins "plus visibles" par les recherches mobiles (je pense a l'impact "retour utilisateur" vis a vis d'un site léger et très adapté face a un site qui serait moins performant car "universel"))

 

[zeb]

si l'information à transmettre, ou l'offre disponible, doit être limitée sur la version mobile, alors autant faire un site à part.

Gros facteur important (dans mon cas) car le site est en effet participatif photo et très littéraire. Donc mes internautes qui me font parvenir des pavés de texte historiques plus leurs 50 photos de vacance sur le "château truc à machin" ne vont pas le faire sur mobile (même si l'idée de coupler leur appareil photo au site m'a traversé l'esprit).

De l'autre côté proposant du contenu très géolocalisé qui serait intéressant a consulter "sur place", par exemple lire l'histoire du "château truc à machin" devant les ruines, il me semble que livrer un contenu allégé (surtout en fonctionnalités) serait un plus.

C'est là la meilleure remarque que j'ai croisé sur le fait d'opter pour des sites différents.

 

[zeb]

entre une souris et un doigt, on n'a pas la même sensibilité. Donc pas évident d'utiliser le même type de navigation

Ça c'est un très gros souci (pour moi), en effet j'ai des rubriques qui ont 100 ou 200 sous rubriques .... Déjà que c'est pas simple en mode PC (j'ai opté pour un select dans la zone de navigation et des liens en footer pour favoriser le crawl naturel).
J'en suis a imaginer un autre truc qui pourrait combiner des actions utilisateurs avec de l'ajax pour naviguer ... (mais bon c'est loin d'être clair pour l'instant surtout si on prend en compte que ça doit tenir dans un écran comme une boite d’allumette)

 

[zeb]

Il faut se méfier de l'idée qu'un utilisateur mobile veuille moins d'information qu'un utilisateur sédentaire.

ça peut se résoudre (après une redirection minimale c'est certains) en gérant une variable de session qui comporte les préférence de l'utilisateur. Bonne remarque en tous cas de ne pas piéger l'utilisateur dans un contexte pas voulu c'est le meilleur moyen de perdre un visiteur.

 

[zeb]

Tout reste en fait disponible, mais la navigation se fait via un menu plus léger, ainsi que par la recherche

c'est paradoxal de parler de menu plus léger dans la mesure ou l'unité de navigation minimale (le lien) doit forcement être plus gros (action via le doigt) et que de fait il prendra donc plus de place (en pixel).

Sinon ta remarque sur la recherche me conforte dans l'idée d'avoir une navigation mieux pensée qu'en version PC en introduisant une grosse interaction entre l'utilisateur et le serveur.

Edit > un gros merci a vous tous pour vos retours, c'est très enrichissant car c'est un domaine ou je suis totalement ignorant.

 

[Leonick]

Tout reste en fait disponible, mais la navigation se fait via un menu plus léger, ainsi que par la recherche

c'est paradoxal de parler de menu plus léger dans la mesure ou l'unité de navigation minimale (le lien) doit forcement être plus gros (action via le doigt) et que de fait il prendra donc plus de place (en pixel).

en fait, c'est plus léger en terme de liens, je pense : quand tu as un menu déroulant à 2 niveaux, mais que tes options ne sont plus sur une ilgne mais en colonne, vu l'exiguïté de l'écran, tes sous-menu se retrouveront à déborder sur l'option suivante et, surtout, si tu veux laisser une taille suffisante pour lire, tes menus verticaux risquent de ne pas avoir toute la place nécessaire pour s'afficher sur ton écran

 

[zeb]

Si vous avez des exemples que vous estimez bien réussis de site mobile visibles en ligne je suis preneur (je peux bidouiller le UA si il faut).

Quelques ressources pour ceux qui les aurait pas vues ou qui veulent un aperçu (j'ai pas encore fouillé dans les dossier d'Olivier)

le point de vue GG sur les sites mobiles (Juin 2012) Et en version longue
Un menu déroulant adapté aux mobiles (Janvier 2012)
tester une page uniquement composée de initial-scale (donne des ordres de grandeurs intéressant en faisant varier l'affichage sur PC)
Un menu de navigation mobile
Quelques bonnes pratique Mobiles qui m'ont interpelées

 

[JanoLapin]

]

Sur la plupart des sites que je monte en incluant une version mobile, le client opte pour un contenu allégé. Tout reste en fait disponible, mais la navigation se fait via un menu plus léger, ainsi que par la recherche

C'est bien là la grosse différence:

* pour les nouveaux sites, on part de la version mobile, et on enrichit jusqu'à la version "desktop". Et là il faut garder présent à l'idée la question: ai-je vraiment besoin d'un site RWD ou de deux sites? (ça dépendra de la différence non de contenu mais "d'offre" entre les deux, notamment navigationelle).

* pour les sites existants, c'est nettement plus problématique: il s'agît de "couper dans la viande", et dans un système de contraintes (menu, css, image, navigation, organisation du contenu, etc.) qui n'a pas été prévu pour ça. Dans certains cas on peut imaginer devoir attendre une grosse refonte prévue du site pour pouvoir passer au RWD.

=> le Responsive design, ce n'est pas seulement une question de design, mais d'abord et avant tout une interrogation sur les objectifs du site


PS: le tuto du jour sur le JdN n'aura échappé à personne. Dans le doute...

PSS: @zeb:: un triple retour d'expérience, un autre point de vue ici

 

[zeb]

Un peut "léger" le tuto du JDN c'est souvent pour ça que j'aime pas trop leur articles. On y trouve aussi du contre le responsive notamment au travers de la monétisation et de la notion de bande passante qui peut être un point très important quand on sort du contexte des 400 mots syndicaux.

On ne perdra pas de vue l’excellente remarque :

Et c'est là l'un des premiers problèmes des media queries. Vous pouvez cibler un écran sur sa résolution, sur sa densité de pixels (pixels CSS, et non des pixels physiques), mais pas sur sa taille physique.

problème de responsive design

A notez que bien que pas fervent de responsive, je m'oriente de plus en plus vers une solution mixte qui consisterait en un domaine dédié et "allégé" qui utiliserait une forme de technologie responsive pour tirer le meilleur parti d'écran assez disparates et réduits.

L'avantage que j'y trouve tiens dans le poids des pages et est lié à la bande passante que ce genre d'appareils peut avoir. Il me semble mais je peut me tromper car je suis pas équipé (ça arrange pas mon problème d'ailleurs) que le trafic est pas forcement illimité avec les équipement mobiles.

Sinon juste pour info, ma quête part du constat par mon outil de tracking que mon trafic mobile est passé de 4% l'an dernier a 7% cette année. Si je pouvais négliger 4% en me disant que c'était pas la mort là on peut espérer que les 7% deviennent 10% sur 2013 et là c'est beaucoup trop important pour que je me permettre de laisser trainer. De plus venant de mettre en ligne une version anglaise du contenu je suppose que cette proportion pourrait s'accentuer en sortant des limites francophones. La difficulté est de ne pas faire n'imp car c'est vraiment pas clair pour moi pour l'instant.

A garder dans un coin, l’adaptation des codes de pub vue par google
Une série de constat sur les problèmes du responsive ici
Media Queries (W3C Recommendation 19 June 2012) pour ceux qui on zappé l'histoire

 

[anemone-clown]

J'ai longtemps hésité, mais les équipes Google Adsense recommandent en formation de faire un site à part entière pour les petits formats d'écran pour les GSM, dans un répertoire nommé "m" (par exemple example.com/m/pagemobile.html). Ils ont, pour ce faire, un excellent outil : http://www.dudamobile.com/ qui permet de transformer votre site en "friendly" mobile en quelques instructions simples. Je vous recommande d'essayer! Attention, si leur service est gratuit la première année (excellent pour tester l'adéquation d'un site "pure"-mobile), ça coûte assez cher ensuite.

La règle de base sur mobile gsm (moins sur les tablettes) : un lien doit pouvoir être cliqué avec le pouce (donc plutôt en bas d'écran)! Sincèrement, j'ai retourné le problème dans tous les sens, et n'ai jamais trouvé le truc avec du responsive design.

J'avais commencé une maquette d'Aquaportail (ici sur iPhone) :

edit : ne pas oublier la gestion spécifique des images de type icônes sur les mobiles : des problèmes de lenteur sur des réseaux en connexion non-3G apparaissent en raison des échanges de cookies; conséquence : certaines images de type icône sont à intégrer en png64 dans le code css et plus du tout en images physiques. Même si cela alourdit le fichier CSS, il n'est lu qu'une seule fois, surtout s'il est hébergé sur un serveur statique!

 

[allstonians]

Quelques chiffres éloquent d'impact d'une migration vers le responsive design : http://www.lukew.com/ff/entry.asp?1691