Part I – Pourquoi les sites Web réactifs ne sont-ils pas une simple étape lors de la construction de sites Web?

Les sites web réactifs (responsive) sont souvent décrits comme un mode de développement permettant de visualiser le contenu, et ce, quel que soit le périphérique de lecture, qu’il s’agisse d’un très grand écran avec une connexion fibre optique, ou bien consulté depuis un téléphone mobile en usant d’une bande passante très faible, ou encore que l’on imprime depuis une imprimante à jet d’encre, sans oublier que ce contenu puisse être parcouru par un lecteur d’écran, ou peut-être visionné dans le hall de l’entreprise sur un téléviseur ultra haute définition 5K.

Bref, les cas d’utilisation sont si largement représentés que l’on ne sait jamais à l’avance où, quand, avec quoi et par qui le contenu sera visualisé. Nous pouvons donc dire que la création d’un site web réactif doit permettre au contenu d’être préparé pour chaque situation.

C’est à peu près ce dont il s’agît, et, d’après les informations envoyées par l’agent utilisateur, lors de la requête http, et le contexte d’utilisation, le contenu sera présenté et formaté conformément à des points d’arrêt définis (breakpoints), ou, s’adaptera de manière liquide en fonction de l’espace disponible.

Nous parlons respectivement d’un affichage adaptable ou réactif (adaptative or responsive).

Sur ce, la plupart des développeurs ont répondu avec une solution qui propose de répondre en priorité aux besoins d’un appareil mobile, et, d’ajouter de plus en plus d’informations, selon l’espace d’affichage disponible.

On appelle cette approche, Mobile First.

Certains autres développeurs ont répondu différemment, en fait de manière opposé, c’est-à-dire en commençant par proposer un affichage optimal et maximal, et en le réduisant en fonction des possibilités du périphérique.

Cela donne naissance à deux concepts aux noms évocateurs, appelés Amélioration progressive et Dégradation gracieuse (Progressive Enhancement and Graceful Degradation).

Comme diraient les anglais, « So far, so good. ».

Tout cela, ne vaut pas sans perdre de vue la question de la bande passante. Et il nous faut impérativement prendre en compte cette dimension.

Il est vrai, que quelle que soit l’approche, les développeurs ont souvent recours à l’affichage, ou au masquage, de certaines parties du contenu en fonction du périphérique de lecture.

Seulement, que le contenu soit affiché, ou masqué, il ne faut pas oublier que l’agent utilisateur, lui, il télécharge tout.

Et à ce point de vue, nous devons également considérer que l’utilisateur fera face à des vitesses de réseau qui peuvent aller de débits liés à la fibre optique jusqu’au goutte à goutte propre aux connexions à faible capacité.

Si nous ne faisons rien, d’une part, le propriétaire du site web paiera pour des octets transférés inutilement et, d’autre part, l’utilisateur devra attendre que toutes les données inutiles aient été récupérées avant d’accéder à l’information.

Cela nous amène à un problème fondamental, souvent oublié: les sites web sont principalement constitués de contenu.

Donc, avant de réfléchir à la façon de présenter ce contenu, et que cela soit de manière réactive ou adaptative, il est important de se poser la question ; à savoir de ce que nous voulons présenter, et bien sûr, en tenant compte du type d’appareil sur lequel ces informations seront distribuées et des bandes passantes qui pourront être alors disponibles.

Pour cela, il nous faut considérer, une véritable stratégie de contenu. Mais, je propose que cette prochaine réflexion sur la mise en œuvre d’une telle stratégie puisse faire l’objet d’un prochain article.