1485 sujets

Web Mobile et responsive web design

Bonjour,

je suis en train d'expérimenter une méthode de développement RWD et je voudrais avoir vos avis.

Mon constat est le suivant : bien souvent, en pur RWD si l'on prend une structure en HTML classique et que l'on lui applique un style différent en fonction des points de rupture des media queries, on obtient pas toujours un résultat idéal à certaines tailles.

Je suis en train de tester un système pour charger le contenu 'visible par le visiteur' de la page avec jQuery selon la largeur du viewport, en rapport avec les media queries de la feuille css.
Mon choix se porte sur 3 contextes : mobile – tablette – desktop, avec des points de rupture à 600px et 1000px.

Chaque page charge un contenu différent en fonction du contexte, bien que ces contenus soient très proches. Cela me permet par exemple de charger des images moins lourdes et moins nombreuses sur la version mobile et de disposer mes menus différemment.

Par exemple pour la page d'accueil, j'ai 3 fichiers :

index_content_small.php
index_content_medium.php
index_content_large.php

qui sont chargés, selon le contexte, dans index.php par une commande load() du style


function loadHero()  {
  $('#outter-wrap').html('');
	
  if   (viewportState == 'mobile') {
	$('#outter-wrap').load('content/' + laPage + '-content-small.php');
  }

  if   (viewportState == 'tablet') {
	$('#outter-wrap').load('content/' + laPage + '-content-medium.php');
  }

  if   (viewportState == 'desktop') {
	$('#outter-wrap').load('content/' + laPage + '-content-large.php');
  }

}

Sachant que je récupère auparavant le nom de la page 'mère' dans la variable js laPage avec le code suivant,

<?php $la_page = 'index'; ?>  
<script>var laPage  = ''<?php echo $la_page ; ,>

dans chaque page (index.php dans cet exemple). J'appelle 'page mère' la page html intégrale dans laquelle viendra se charger le fragment de code présent dans l'une des 3 pages définies plus haut.


<div id="outter-wrap"></div> contient donc tout le contenu de la page visible à l'internaute.
Bien sur, dans chaque page mère, j'ai déjà un contenu qui sera affiché si javascript n'est pas activé (ce qui devient de plus en plus rare admettons le) et que je remplace avec mon code js. viewportState est une variable js que je créé en mesurant le viewport avac javascript.

Je sais que certains d'entre vous vont me dire que ce principe oblige à faire les mises à jour de contenu dans 3 fichiers différents à chaque fois, mais c'est un choix assumé : le site est simple et son contenu ne sera pas mis à jour très souvent, mais l'aspect design est très important et je veux des mises en pages ultra précises dans chaque contexte.

Je n'ai jamais entendu parler de cette méthode en me documentant sur le sujet mais je ne dois sûrement pas être le premier à y penser.

Est ce que ça peut poser un problème avec Google, sachant que 3 versions différentes (même si les contenus sont ultra proches) de chaque page peuvent transiter sur le net ?

Ce post est aussi en relation avec celui ci, il le développe...

merci
Modifié par lionel_css3 (24 Nov 2013 - 18:56)
Bonsoir,

Personnellement je trouve que l'histoire des points de rupture est souvent mal utilisé ou mal pensé et a finalement un effet contraire à celui recherché.

Je m'explique ...
autant sur un smartphone ou une tablette, le viewport sera utilisé a 100% autant sur un pc ce n'est pas le cas , et qu'est ce que ça me gonfle un site qui m'oblige a scroller horizontalement ou à faire du 100% de la fenêtre ou de tâter pour un break-point pour avoir une consultation confortable.
Il y a longtemps que nos PC sont multi-tâche Smiley smile .

L'idée de charger des "quantités" de contenu différentes en fonction, à priori, du media du visiteur n'est pas une mauvaise idée si il est trier/extrait d'une bdd, mais à partir de 3 sources c'est 3 fois plus couteux et 3 fois plus à maintenir, 3 fois plus a referencer sur une même URI, c'est courageux.
Il y a peut-être aussi la bande passante qui peut avoir son importance quant au poids du contenu a servir Smiley smile
++
Modérateur
gc-nomade a écrit :
Je m'explique ...
autant sur un smartphone ou une tablette, le viewport sera utilisé a 100% autant sur un pc ce n'est pas le cas , et qu'est ce que ça me gonfle un site qui m'oblige a scroller horizontalement ou à faire du 100% de la fenêtre ou de tâter pour un break-point pour avoir une consultation confortable.
Il y a longtemps que nos PC sont multi-tâche Smiley smile .

Parfaitement, d'ailleurs j'ai très vite abandonné de réfléchir en terme de breakpoints officiels. Mes breakpoints généralement sont mis à la résolution à partir de laquelle un problème de mise en page est constaté. Du coup mes breakpoints changent de site en site.
La question que je pose n'a absolument rien à voir avec les points de ruptures...en fait.

J'ai signalé aussi dans mon post que j'étais conscient qu'il y a 3 sources différentes à maintenir mais que ce n'était pas un problème et que j'assumais..

Je trouve qu'avec ce principe on peut réaliser un design optimal pour chaque contexte.


Ce qui 'interroge principalement c'est de connaitre le comportement vis à vis de Google,
quelle est la version indexée...?
Salut,
lionel_css3 a écrit :
Ce qui 'interroge principalement c'est de connaitre le comportement vis à vis de Google,
quelle est la version indexée...?

Aucun, je le crains.
Modérateur
Pour en revenir au sujet.

a écrit :
Connaissez vous cette méthode de responsive design ?

Non car ce n'est pas vraiment une technique de responsive web design. C'est plutôt une adaptation du principe de site mobile / site desktop qui s'appuie sur l'analyse de la taille du nivagateur au lieu de la détection d'user-agent.
Un des principe fondateur du RWD (responsive web design) est de fournir le même contenu, mais d'adapter sa présentation. Ce principe a lui-aussi ses faiblesses mais celui que tu utilises n'est définitivement pas du RWD.

a écrit :
Ce qui 'interroge principalement c'est de connaitre le comportement vis à vis de Google,
quelle est la version indexée...?


Le robot de base de google n'a pas de "taille" d'écran.
Le robot mobile de google n'a pas de taille non plus, mais analyse les media-queries pour observer les changements.
Les robots google exécutent une partie de javascript mais pas tout. Ils peuvent faire de l'ajax.
Google ne va pas bien comprendre ce "bricolage", il faut voir comment tu calcule ta variable viewportState. Le mieux reste de faire un test, sur une page que tu possèdes. (en fournissant une version de base, et 3 version chargées avec des termes très différents pour voir ce qu'il prend en compte). Comme les algorithmes de Google sont secret et qu'on en a que des estimations, seul des tests peuvent donner des réponses pour des questions aussi délicates. Il ne faut pas oublier que le moteur évolue et que sa manière de traiter ce cas pourra changer.

a écrit :
Mon choix se porte sur 3 contextes : mobile – tablette – desktop, avec des points de rupture à 600px et 1000px.

Là où gc-nomade a furieusement raison, c'est que c'est une erreur de mettre au même niveau tailles d'écran, contextes de navigation, et appareils.

D'ailleurs qu'est ce qui se passera avec une tablette, qui dans ton cas sera considérée comme tablette en portait, et desktop en paysage? Le contenu se recharge et change? ça risque d'être plutôt dérangeant.
kustolovic a écrit :

il faut voir comment tu calcule ta variable viewportState.


de la façon suivante:


var sw;
var viewportState = "desktop";
var firstRun = true;


$(document).ready(function() {


dimSet();
$(window).resize(dimSet);


/* ----------------------------------- */
/*         function dimSet           */
/* ----------------------------------- */

function dimSet()  {
  sw = viewport().width;
  if (sw > 999) { 
	desktop();
  } else if(sw > 599 && sw < 1000) {  
	tablet();
  } else if(sw < 600) {  
	mobile();
  } 
}
 
/* ----------------------------------- */
/*         Traitement Desktop          */
/* ----------------------------------- */
function desktop()  {

  if (viewportState != 'desktop' || firstRun == true) { // vient de passer à l'état desktop
	viewportState = 'desktop';
	loadHero();	
	firstRun = false;
  }
}

/* ----------------------------------- */
/*         Traitement tablet           */
/* ----------------------------------- */
function tablet()  {
  if (viewportState != 'tablet' || firstRun == true) { // vient de passer à l'état tablet
	viewportState = 'tablet';
	loadHero();	
	firstRun = false;
  }
} // function tablet()


/* ----------------------------------- */
/*         Traitement mobile           */
/* ----------------------------------- */
function mobile()  {
  if (viewportState != 'mobile' || firstRun == true) { // vient de passer à l'état mobile
	viewportState = 'mobile';
	loadHero();	
	firstRun = false;
  }
}

/* ----------------------------------- */
/*         function loadHero           */
/* ----------------------------------- */
function loadHero()  {
  $('#outter-wrap').html('');
	
  if   (viewportState == 'mobile') {
	$('#outter-wrap').load('content/' + laPage + '-content-small.php');
  }

  if   (viewportState == 'tablet') {
	$('#outter-wrap').load('content/' + laPage + '-content-medium.php');
  }

  if   (viewportState == 'desktop') {
	$('#outter-wrap').load('content/' + laPage + '-content-large.php');
  }

}
  

/* ------------------------------------ */
/*    function viewport                */
/*    calcule dimensions viewport      */
/* ----------------------------------- */
function viewport() {
	var e = window, a = 'inner';
	if (!('innerWidth' in window )) {
		a = 'client';
		e = document.documentElement || document.body;
	}
	return { width : e[ a+'Width' ] , height : e[ a+'Height' ] };
	}

});  // ----------  fin du ready


kustolovic a écrit :

Là où gc-nomade a furieusement raison, c'est que c'est une erreur de mettre au même niveau tailles d'écran, contextes de navigation, et appareils.


mais non,je n'ai pas raisonné par rapport aux appareils.... j'ai employé les termes mobile, tablet et desktop pour m'y retrouver.. c'est tout...
je réponds ici à victor bruto qui me répondait dans un autre post pour un sujet similaire.

Victor BRITO a écrit :
Salut,

Je crains que Google ne se contente de considérer la page en question comme ayant du contenu vide.

Par ailleurs, pourquoi charger le contenu en JavaScript / Ajax (avec les problèmes de performances lorsque la connexion mobile ne jouit ni d'un réseau Wifi ni de la 4G ni de la 3G) ?

Si c'est pour livrer du contenu différent en fonction du type d'écran tout en faisant du responsive, c'est qu'il y a un problème quelque part, à mon avis… Smiley sweatdrop


mais si il y a un contenu au départ dans ma page, elle ne sera pas vide ..

dans la matinée je reviendrai avec un schéma pour bien expliquer ce que je veux faire.

Concernant la performance, je ne charge que du html et je ne charge pas à coté 15 librairies javascript comme je le vois souvent dans des pages web 'soit-disant RWD' que j'examine...
et puis tous les gens que je vois consulter internet sur un téléphone me disent toujours, avec le sourire 'c'est un peu long, il faut attendre' lol, les gens ne sont pas hargneux pour ça. Smiley smile
Modifié par lionel_css3 (25 Nov 2013 - 09:10)
Bonjour,

ce n'est pas du responsive webdesign que tu fais mais de l'ajax et est ce que tu as besoin d'ajax ?

Si oui, renseignes toi sur la manière d'indexer ton site avec ajax. A priori, je pense que google devrait indexer le contenu par défaut et suivre les liens à conditions que tu prévois une version accessible sans js.

Si non, tu fais ça côté serveur, comme tout le monde j'ai envie de dire.

Aussi pour éviter que google indexes 3 fois les mêmes contenus tu peux utiliser rel="canonical"
bon, voila, pour éclairer ma démarche, voici un schéma fonctionnel.

upload/40948-sch-foncti.jpg

en fait , au départ, ma page n'est pas vide, elle a un contenu qui s'affiche si javascript ou Jquery n'est pas actif, et ce contenu serait pris en compte par google si j'en crois ce qiue je lis plus haut dans vos réponses.
Maintenant quelques explications pour éclairer mon choix par rapport au design.
sur l'image jointe, les 3 contextes:

la balise <header> est entourée de rouge:

Dans les contextes small et medium (j’arrête de les appeler mobile et tablet puisque ça en trouble certains Smiley lol ) le menu <nav> est contenu dans le header.
Dans le contexte large, le <nav> est hors du <header> et floaté différemment en vertical.

Dans le contexte small , il y a un graphique à gauche dans le header, dans les autres contextes c'est une photo.
Dans le contexte small il n'y a pas de logo à droite dans le header, dans les deux autres contextes, il y en a un.

Voila donc, fondamentalement le contenu est très proche mais le html, au niveau structurel , doit être un peu différent.
Il y aura assez peu de contenu dans le site, par contre le destinataire est très sensible à l'aspect final graphique ( qui est encore provisoire dans ce que vous voyez)

upload/40948-contextes.jpg
bzh a écrit :
Bonjour,

ce n'est pas du responsive webdesign que tu fais mais de l'ajax et est ce que tu as besoin d'ajax ?

Si oui, renseignes toi sur la manière d'indexer ton site avec ajax. A priori, je pense que google devrait indexer le contenu par défaut et suivre les liens à conditions que tu prévois une version accessible sans js.

Si non, tu fais ça côté serveur, comme tout le monde j'ai envie de dire.

Aussi pour éviter que google indexes 3 fois les mêmes contenus tu peux utiliser rel=&quot;canonical&quot;


ta réponse s'est croisée avec ma réponse (illustrée) Smiley smile

Ben si, c'est du responsive puisque je sers un contenu en fonction du viewport, voir le code js plus haut qui est un genre d'équivalent de matchMedia.

coté serveur, en PHP, je ne sais pas comment charger un contenu différent en fonction du viewport, y compris après un resize... mais je suis ouvert à toutes suggestions, sinon je ne serais pas ici.


(edit) concernant le rel=canonical, j'ai mis mes fragments HTML chargés dans un dossier qui ne sera pas indexé ( disallow), ça ne suffit pas??
Modifié par lionel_css3 (25 Nov 2013 - 11:31)
Modérateur
lionel_css3 a écrit :

Ben si, c'est du responsive puisque je sers un contenu en fonction du viewport, voir le code js plus haut qui est un genre d'équivalent de matchMedia.

Ben non justement, servir un contenu différent ce n'est pas du responsive. Le principe du responsive est de servir le même contenu, et mettre un ensemble de techniques en oeuvre pour que le site s'affiche bien à toutes les tailles: grilles fluides, images fluides ou semi-fluides, media-queries, etc.

lionel_css3 a écrit :
Concernant la performance, je ne charge que du html et je ne charge pas à coté 15 librairies javascript comme je le vois souvent dans des pages web 'soit-disant RWD' que j'examine...
et puis tous les gens que je vois consulter internet sur un téléphone me disent toujours, avec le sourire 'c'est un peu long, il faut attendre' lol, les gens ne sont pas hargneux pour ça. Smiley smile

Le responsive n'est pas la seule technique possible. Son désavantage est justement qu'en servant la même chose à tous, ce n'est pas du tout optimisé par situation. Le responsive n'est pas une technique pour faire des sites mobiles, mais une vue plus globale de la manière de fournir un contenu pour tous les cas. Pour les problèmes de chargement, le mobile-first est une manière d'avoir une approche plus optimisée (mais dans ce cas souvent pour tous).

Autrement pour accroitre les performances, on sert plutôt un autre contenu (optimisé) par le serveur, ça a aussi ses inconvénients mais on peut avoir facilement de bonnes performances ainsi.

Là, ta solution enchaîne deux chargements consécutifs pour afficher la page. Ce n'est pas du responsive, et les performances seront médiocres. J'ai de la peine à voir l'intérêt.

Finalement en voyant tes maquettes, les différences sont tellement faibles que c'est typiquement un cas ou le responsive apporte très peu de problèmes, et est un grand avantage. De plus avec une bonne structure, nul besoin de réécrire ton HTML pour obtenir ces différences. Et si tu te soucies du supplément de temps pour charger une image qui ne s'affiche pas, ce sera toujours moins pire de que de charger la page pour pouvoir commencer à charger le contenu.
Et il faut se poser aussi la question si offrir une image différente en fonction de la taille a du sens? Pourquoi un usager mobile n'a pas le droit de voir la bouille du dentiste, pourquoi un usager desktop ne peut pas voir un graphique? Parfois servir un contenu différent peut avoir du sens. Là ce n'est pas le cas.
kustolovic a écrit :

Le principe du responsive est de servir le même contenu, et mettre un ensemble de techniques en oeuvre pour que le site s'affiche bien à toutes les tailles: grilles fluides, images fluides ou semi-fluides, media-queries, etc.


c'est ce que je fais !! le contenu est le même, avec quelques subtilités. Si le nav est contenu dans le header dans un cas et si il est hors du header dans l'autre cas, le contenu est quand même le même.


kustolovic a écrit :

Et il faut se poser aussi la question si offrir une image différente en fonction de la taille a du sens? Pourquoi un usager mobile n'a pas le droit de voir la bouille du dentiste, pourquoi un usager desktop ne peut pas voir un graphique? Parfois servir un contenu différent peut avoir du sens. Là ce n'est pas le cas.


au contraire, ça a du sens .. l'image que je prévois de mettre à gauche dans le header ressemble à rien, elle est illisible, une fois réduite dans le contexte small. Je la remplace par un graphique plus simple, qui est une représentation de l'image qui est bien mieux lisible. De plus, je prévois de remettre cette image 'amputée' dans le corps de la page (en contexte small).

Pareillement, la site contient une page avec une galerie d'images
Dans le contexte medium et large je prévois un slider de taille respectable avec tous ses boutons alors que dans la version en contexte small je prévois moins d'images, cadrées différemment et cote à cote verticalement