Part IV – Transposer le contenu vers une présentation
Article 1 sur 5 de la série: Quid du Responsive Web Design
- Part IV – Transposer le contenu vers une présentation
- Part III – Quelles sont les attentes de l’utilisateur pour votre site Web? Cela dépend du contexte.
- Part II – Pourquoi une Stratégie de contenu doit précéder la mise en place d’un site Responsive Web Design?
- Part I – Pourquoi les sites Web réactifs ne sont-ils pas une simple étape lors de la construction de sites Web?
- Quid du Responsive Web Design
Avant de porter le contenu en ligne, nous devons réfléchir à deux problèmes distincts, qui sont partagés entre l’aspect technique du Responsive Web Design et la présentation qui doit être orientée et guidée par la stratégie de contenu définie précédemment.
Nous devons décider: « Qu’est-ce que nous affichons? » Et « Comment nous l’affichons? »
Voici quelques-uns des comportements clés qui interagissent entre RWD et Stratégie de contenu. Chaque choix, ou solution, sera défini en fonction du périphérique et du contexte, et ne devra aucunement affecter l’intégrité du contenu:
- La taille de la police doit être adaptée en fonction de la taille de l’écran, plutôt grande pour les grands écrans et réduite sur les petits écrans, afin de pouvoir apporter une plus grande visibilité,
- Selon le type d’appareil, la famille de polices doit répondre à une meilleure lisibilité, habituellement on utilise des fontes Serif pour l’impression, et Sans-Serif pour l’écran,
- La barre de menus, ainsi que les outils de navigation, doivent être réduits à une icône (hamburger) sur un petit appareil et complètement supprimés lors de l’impression,
- D’une manière plus générale, lors de l’impression de contenu, il est recommandé de supprimer toutes les parties inutiles de la page, comme le pied de page, les outils de navigation, les animations. Il est également intéressant de s’assurer de ne pas trop utiliser de couleurs qui consommeraient beaucoup d’encre. De même il peut être important de garder à l’esprit que la plupart des utilisateurs puissent imprimer en noir et blanc,
- Lors de l’utilisation d’images, il faut décliner leurs tailles et leurs résolutions afin de pouvoir plus facilement répondre aux divers type d’écran: est-ce un écran Retina ou un écran de base, est-ce un écran large ou un écran de petite taille ?
- Lorsque des données tabulées, ou de grands tableaux, doivent être affichées sur petits écrans, nous devons absolument repenser leur présentation,
- Le Web, la souris et le multimédia nous ont enseignés l’état interactif lors de survol. Parfois, cet affichage contient des informations cruciales, il nous faut donc prévoir un mécanisme pour redistribuer cette information, lors de l’emploi d’appareil tactile,
- Nous devons remplacer les galeries d’images qui sont trop gourmandes en bande passante lorsqu’elles sont visionnées en bas débit, ou affichées sur des périphériques n’ayant quasi plus de batterie, ou encore parcouru par un lecteur d’écran,
- Pensez en termes d’accessibilité quant aux informations et aux outils de navigation lorsque le contenu sera visualisé à partir d’un lecteur d’écran,
- Définir un choix éditorial qui propose le contenu dans un genre: masculin, féminin, les deux? L’utilisation d’acronymes? L’appui sur des schémas et/ou des illustrations? Tout cela, bien sûr, dans un souci d’accessibilité et de présentation,
- Toujours fournir non seulement des sous-titres, mais aussi une transcription lors de l’emploi de vidéo. Penser aussi à l’établissement de points de repère, pouvant être utilisés comme déclencheurs, ou Breakpoints,
- Anticiper l’adaptation des formulaires interactifs, afin de pouvoir répondre aux diverses plateformes de distribution partagées entre écrans et souris, tablette tactiles et smartphones, braille et voix, ou encore documents imprimés
- Créez des Breakpoints en étroite relation avec le texte ; dépendant du nombre de caractères par ligne, de l’orientation des périphériques, des expériences ou des préférences de l’utilisateur, et non basés uniquement sur des repères purement techniques,
- En ce qui concerne les Breakpoints, nous devons également inclure des aspects techniques liés au contexte d’utilisation, comme le faible niveau de batterie, les connexions bas débit, l’utilisation au soleil ou sous forte lumière, les réflexions possibles sur l’écran, la géolocalisation de l’utilisateur, ou encore le relais obtenu par un opérateur tiers. Bref, tous ces aspects techniques qui ne sont pas directement liés aux performances de l’appareil en lui-même,
- La problématique majeure à prendre en compte lorsqu’on travaille avec une grande quantité de contenu est de pouvoir éviter toutes données téléchargées qui ne soit pas absolument nécessaire à l’utilisation. Nous devons réfléchir à la façon de pouvoir remplacer chaque élément non essentiel lors d’une utilisation particulière, ou de pouvoir afficher, ou proposer, une solution alternative,
- L’objectif final est que l’action, l’interaction et l’information ne doivent jamais être bloquées, ou conduire à un cas d’utilisation différent, simplement parce que l’utilisateur visite la page, ou utilise le contenu, à partir d’un périphérique différent.
La liste ne s’arrête pas ici, mais elle nous permet déjà de considérer, et, de mieux comprendre la nécessité d’une telle stratégie de contenu à chaque fois que nous prenons en compte l’aspect réactif d’une conception Web.
Comment gérer le contenu par le programme?
Une pure approche basée sur le code n’étant pas l’objectif de cette série d’articles, je vous invite à nous rejoindre au cours d’autres publications, où nous pourrons mieux explorer ensemble chaque technique, et solution, de manière plus verticale.
Il s’agit donc ici de ne se concentrer que sur les diverses familles de chaque solution afin de gérer les différentes techniques RWD:
- La mise en place de MediaQueries qui relient différents fichiers CSS en fonction du contexte, du type de périphérique utilisé et de ses capacités,
- Combiner les diverses MediaQueries de la page en définissant de manière stratégique aussi bien des Breakpoints principaux que des Breakpoints secondaires. Cela permettra d’affiner la bascule entre les divers affichages, et mises en page, et, éventuellement, de pouvoir charger de nouveaux contenus complémentaires,
- Prévoir de multiples sources médias, correspondant à différentes qualités et/ou tailles d’image, en utilisant l’attribut srcset = « »
- Employer la nouvelle balise <image> qui peut également nous aider, et compléter l’élément précédent, sur les stratégies de présentation mises en place,
- Le support natif de l’instruction JavaScript, matchMedia (), qui couplée à des techniques d’AJAX, nous permet de ne charger que les données nécessaires en fonction du périphérique, et du contexte d’utilisation,
- L’utilisation de nombreux Shim et Polyfills afin de compléter les manques de certains navigateurs trop anciens,
- Déployer une mécanique JavaScript afin de servir un défilement infini (infinite scrolling). De cette façon, lorsque l’on a à faire à une faible bande passante, il est possible de ne charger, au fur et à mesure, que la partie visible du contenu, évitant ainsi de charger ce qui ne sera peut-être pas vu,
- Revoir le mécanisme d’accordéon, ou d’onglets, qui peut ainsi charger des données à la demande sans devoir changer la page, et toujours selon la bande passante,
- Il est important d’optimiser le site Web en: échantillonnant les fontes lorsque possible (subsetting), compresser les données du côté du serveur (gzip, deflate), concaténer et minimiser les scripts et CSS (uglify, minify), supprimer toutes les lignes de code et les commentaires inutilisés, utiliser des CDN lorsque nécessaire, optimiser l’ensemble des fichiers image (tinypng),
- Optimiser la gestion du cache. Cela se réfère souvent à l’API Service Worker, employée pour les WebApp, qui nous aidera à minimiser l’utilisation de la bande passante, et, le transfert de données lors de l’utilisation du même appareil ou du redimensionnement des fenêtres,
- Si possible, obtenez des analyses de trafic de vos internautes cibles afin d’aider à prioriser les approches,
- Et du fait que certains points ci-dessus se réfèrent à l’utilisation de Javascript, il faut absolument fournir une autre approche alternative basée sur l’utilisation de la balise <noscript>.
Et maintenant?
Ce dernier article de la série dédiée à la mise en œuvre d’une approche réactive, est maintenant terminée.
Rappelez-vous que le portage d’un site en techniques RWD doit se baser sur une réelle stratégie de contenu, qui prend également en compte le contexte d’utilisation, et ne pas simplement proposer une alternative de présentation réagissant uniquement à des largeurs d’écrans.
L’objectif principal de cette série étant de nous amener à réfléchir, et à nous poser les bonnes questions, sur la façon d’améliorer l’implémentation réactive des contenus pour tous nos projets, je vous invite à nous retrouver au cour de prochains sujets aussi bien verticaux que transversaux concernant aussi bien le RWD que la Stratégie de contenus.
6 réponses
[…] Transposer le contenu vers une présentation […]
[…] Transposer le contenu vers une présentation […]
[…] Transposer le contenu vers une présentation […]
[…] Transposer le contenu vers une présentation […]
[…] Transposer le contenu vers une présentation […]
[…] Part IV – Transposer le contenu vers une présentation […]