Responsive Web Design, mon grain de sel ;)

Les tailles des écrans varient énormément, et ce phénomène ne fait que s’amplifier.

Les nagigateurs se diversifient, sans qu’on voie de réelle convergence arriver. En fait, comme l’historique du web augmente (mécaniquement 😉 ) et qu’on ne contrôle pas les mises à jours des logiciels, le nombre de navigateurs augmente mécaniquement, au fil du temps.

Le contexte de l’internaute est de plus en plus varié : chez lui, avec un ordinateur, chez lui, avec une tablette, une console de jeux mobile ; en mobilité, avec un smartphone, …
Ce contexte est important, parce qu’en fonction de celui-ci, les problématiques ne sont pas les mêmes : la bande passante n’est pas du tout la même, entre un internaute qui accède à un réseau wifi et un internaute en mobilité, en 3G ou Edge.

Enfin, même quand l’internaute est chez lui, devant un bien classique ordinateur, la taille de la fenêtre du navigateur peut tout à fait ne couvrir qu’une partie de son écran.

Bref, le contexte de navigation devient de plus en plus varié, avec pas mal de paramètres à prendre en compte.

D’ou la tendance actuelle, intéressante, du Responsive Web Design.

Cette notion vient de l’architecture physique, ou l’on essaye de faire des éléments qui évoluent, en fonction des besoins ou usages.
Exemple : une vitre est transparente et peut devenir opaque, en fonction de l’usage de la pièce.

Je veux pas la ramener, mais c’est bien ce à quoi Wokup s’était attelé dès 1999 !

Donc, ce n’est pas un sujet nouveau, mais on peut dire que c’est un sujet qui devient de plus en plus important.

L’idée, du Responsive Web Design, c’est de changer la façon de concevoir un site web, de manière à ce qu’il soit « intrincèquement » adaptable aux différentes configurations.

On a bien l’idée d’un contenu unique, qui s’adapte à l’ensemble des situations.

 

Ce que j’en pense :

C’est un vrai sujet, c’est donc très bien qu’il soit traité 😉

Comme le dit ce très bon article (en Français en plus), cela ne concerne pas que la partie technique. Il faut que les designers pensent au site différemment, le conçoivent différemment.
Il faut dans le même temps que les décideurs, les manageurs, comprennent ces enjeux, et fassent des choix cohérent par rapport à ce besoin, qu’ils demandent à leurs agences : « comment le site s’adapte aux différentes tailles d’écrans » ?

Si le buzz actuel sur cette approche fait bouger les choses dans ce sens, et aide l’ensemble des acteurs : développeurs, designers, décideurs, c’est déjà très très bien !

Maintenant, l’approche est intéressante, mais n’est pas suffisante.

Je ne pense pas, pour ma part, que le seul sujet soit la mise en forme, aussi intelligente soit-elle.
Exemple : on ne va pas afficher le même nombre de produits, entre une interface pour smartphone et un ordinateur.

Je ne vois pas non plus pourquoi on envoie le même contenu à l’internaute, quelque soit sa configuration.

Je sais que ce n’est pas l’approche « standard », mais je pense qu’il est plus adapté, pour certains éléments, d’envoyer un contenu adapté à la configuration de l’internaute.

Exemples :

  • il est en mobilité, sur un petit écran : j’envoie des images petites, légères.
  • Il est chez lui, avec un bon réseau : j’envoie des images en haute définition, permettant d’avoir une qualité au top.
  • Il navigue depuis IE6 😉

Bref, je pense que la solution passe par un mixe entre ce que propose le Responsive Web Design, et des technologies côté serveur.

La partie Responsive Web Design permet d’avoir un contenu avec une certaine élasticité.

La partie serveur permet d’optimiser ce qu’on envoie à l’internaute, tant au niveau du poid qu’au niveau du format.

Maintenant, l’approche dont je parle n’exsite pas…. Pas encore !

Merci à

8 commentaires

  1. Ce qui n’aide pas non plus d’en l’envie de servir un contenu différent en fonction de l’environnement de l’utilisateur c’est :

    – Il plane toujours la possibilité d’être compris comme du cloaking
    – La difficulté de faire le tri dans les user-agent aujourd’hui
    – Une URI = un contenu unique et difficile de dérogé à ce principe

  2. @Seza> Reprenons les points un par un.

    Cloaking : Il faut faire attention au cloaking quand on développe cette approche. Mais si on lit la définition du cloaking, cela ne couvre pas le cas ou on fournis une page différente si l’internaute est sur IE6. Après, il faudrait faire des tests, pour voir si une telle techno serait « punie » par Google.

    Tri dans le User Agent : pourquoi ? Quel est le problème ?

    URI : c’est une approche dogmatique ? Sinon, quels sont les difficultés ?

  3. Cloaking : Oui ce n’en est pas la définition mais ça s’y apparente rapidement. Comme tu le dis, il faudrait testé les réactions de Google.

    UserAgent :
    – Pourquoi ? Identifier à quel Interface nous avons à faire.
    – Le problème ? Liste-moi tous les user-agents existant aujourd’hui.
    C’est le seul moyen (non fiable) d’identifier un support avant d’y envoyer un contenu. seulement les user-agent peuvent être trompeur, changé, leur liste n’est ni standardisé ni exhaustive, de nouveau user-agent apparaissent tous les jours pour chaque couple OS/support pouvant exister.
    Ce qui rend ce travail d’identification de support bien difficile à effectuer.

    URI : dogmatique, je dirai oui bien sur.
    Si le contenu renvoyé par le serveur est adapté au support il n’est pas unique pour une URI donnée. Sémantiquement parlant, un contenu différent = une uri différent. Hors à partir du moment où l’uri de la dite version spécifique est partagée, l’intérêt de servir une version adaptée est perdu. Si l’on garde la même URL pour différente version d’un même document en fonction de la « variance » de la structure de la page on peut se demander jusqu’où on à a faire au même document ou à des documents différents. Hors ceci n’est pas clairement défini aujourd’hui.
    Si ce point est plus rhétorique que le reste, cela reste important et il peut en découlé de vrai problème technique (et d’indexation, si google condamne le duplicate content c’est bien qu’une ressource n’a qu’une adresse (et inversement ?) et l’on ne peut être référencé dans google news que si l’on a une URI par article).

    C’est pourquoi, au final, il est bien plus simple d’avoir un contenu unique servi par url qui s’adapte dynamiquement côté client à son support.

  4. Effectivement, un vrai sujet : nous y travaillons justement.

    L’objectif, dans un premier temps, est de servir des templates adaptés à chaque plate-forme (y compris en terme de tailles d’image, pour les produits notamment), ce qui compliquera les futures évolutions de charte, mais ce qui permettra d’améliorer l’expérience client.
    Le cloaking devrait donc être nul, puisque tout sera à base de templates affichant les mêmes données.

  5. Bonjour François,
    Il existe une approche qui permet de combiner responsive design et partie serveur pour envoyer ou non certaines infos au clients : RESS.
    Le serveur enregistre la taille de l’écran et en fonction de la taille de l’écran on peut envoyer différents formats d’image par exemple ou ne pas afficher une description etc…

  6. Je suis plutôt d’accord avec @Seza
    En pratique se baser sur le User-Agent est mission impossible. La diversité des navigateurs / OS est trop importante. Il n’existe aucune certitude que tout se passe bien pour tout le monde.

    L’adaptabilité en fonction de la taille de l’écran est la meilleur des solutions, avec une très bonne illustration sur ce site : http://framelessgrid.com/ (grille non fluide)

  7. Merci Matthieu 🙂

    Pour repartir sur l’idée de François : « Servir du contenu adapté au mobile », voici ma réflexion.

    On démarre généralement par la conception d’une page web standard, puis on va l’alléger, supprimer le contenu facultatif etc… pour voir naitre une page web mobile.

    On dérive un contenu de base dans un mode dégradé adapté au mobile.

    Ne devrait-on pas plutôt aujourd’hui créer nos sites web de base pour mobile et faire du responsive design lorsque la largeur d’écran augmente, de manière à enrichir le contenu ?

    Il est fort probable que le résultat entre les deux méthodes arrivent à un rendu identique à la différence près que ce ne sera plus la partie mobile qui supportera la surcouche d’adaptation (ce qui semble bien plus logique).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.