Les défauts des images par défaut

Design & image par défaut

Sur Osuny, les développeurs et développeuses d’un site ont la possibilité de renseigner une image par défaut, utilisée dans les objets post, event, page, paper et volume.

Actuellement, la méthode est la suivante : il faut ajouter au dossier /static/assets/images un fichier default.png/jpg, puis ajouter au fichier /config/_default/config.yaml les paramètres ci-dessous (ou un seul) :

posts:

    default_image: true

events:

    default_image: true

Une fois ceci fait, actualités et événements sans image prendront celle par défaut.

Néanmoins, cette méthode nous semble aujourd’hui dépréciée, en particulier parce que le partial hugo utilisé (image-default.html) pose plusieurs problèmes : 

  • Il ne permet pas de gérer les cas où une image serait dans un autre format (svg, jpeg…), ni le cas de l’ajout d’une image rétina ;
  • Il doit impérativement être refactorisé, car actuellement le code traite de façon identique les deux cas de “.png” et “.jpg”. On pourrait envisager l’utilisation d’une variable à la place de l’extension en dur.

SEO & image de partage

Ces problématiques soulèvent également une interrogation, au sujet de l’image par défaut utilisée pour partager des pages et articles d’un site, d’une part parce que le problème est le même au niveau de l’imposition des extensions (strictement share.jpg ou share.png), d’autre part parce que cela pose plusieurs questions :

  • Faut-il ajouter à Osuny une image share par défaut ? Actuellement, il faut en ajouter une au dossier static/assets/images/.
  • L’image de share doit-elle être identique à celle par défaut (ou inversement) ?
  • Du point de vue de l’écoconception, moins il y a d’image, plus les sites sont légers. Néanmoins, les posts sociaux ont moins d’impact sans média ; il faut donc s’attendre à ce que les éditeurs et éditrices des sites en fassent souvent la demande.

Solutions potentielles

Modifiable(s) dans le back-office ou dans le code ?

  • Pendant le développement

Actuellement, l’activation de l’image par défaut se fait par les développeurs et développeuses dans la config.yaml du site.

Par rapport au travail des développeurs et développeuses, plusieurs solutions peuvent être envisagées, au moins pour l’image par défaut. Actuellement, on peut activer cette dernière pour les actualités et les événements séparément.

Pour pousser cette méthode de façon plus logique, plutôt qu’indiquer dans le partial hugo le chemin vers l’image, pourquoi ne pas faire comme on le fait actuellement pour le logo, de cette façon, directement dans la configuration du site :

posts:

    default_image: false

events:

    default_image: "/assets/images/default.jpeg"

NB : ce n’est pas très élégant de procéder de cette façon, car cela implique d’avoir une condition false / “image.jpg”, au lieu d’un véritable booléen.

Le problème du partial actuel est aussi en lien avec l’amélioration des performances du site. Dans un souci d’éco-conception, il faut pouvoir indiquer des tailles aux images, via les attributs width et height (utiliser les tailles appropriées permet d'économiser des données mobiles et de réduire le temps de chargement). Du point de vue du design, cela permet d’éviter les sauts de mise en page (notamment entre la version ordinateur et celle mobile/tablette).

Actuellement, les images adaptatives sont bien présentes sur Osuny, mais elles sont gérées par le CDN, qui fournit leur différentes variantes (13 au total). 

En s’appuyant sur ce système, sans aller plus loin que nécessaire, on aurait donc 9 variantes, prenant en compte 2 breakpoints au lieu de 3 :

  • L’image d’origine ;
  • Deux images par breakpoints (4 donc) ;
  • Deux images retina ;
  • Une image pour les navigateurs qui ne gèrent pas le format adaptatif.

Dans le cas de nos images par défaut, actuellement, elles ne bénéficient pas de cette fonctionnalité. Néanmoins, si l’on passe l’ajout des images par défaut et de partage dans le back-office, il sera alors possible d’utiliser cette méthode pour les images affichées sur le site. En revanche, lors du partage d’une page, seule une version de cette image pourra être utilisée.

  • Depuis le back-office

Pour l’image de partage, dans le cas où une image serait administrée depuis le BO et appliquée à toutes les pages, l’idée pourrait être d’avoir deux champs d’images : un premier, déjà existant, pour mettre une image d’illustration, ainsi qu’un deuxième propre au partage.

Une image de partage propre à chaque objet ?

L’une des options serait de permettre aux utilisateurs et utilisatrices, depuis le BO, de renseigner une image de partage par défaut, modifiable ensuite au cas par cas dans les objets (posteventpapervolumepageperson).

Que ce soit via le back-office ou via la configuration du site, on peut alors se demander jusqu’où est-ce que l’on doit aller dans la personnalisation : 

  • Une image de partage globale ;
  • Une image de partage optionnelle pour chaque type d’objet ;
  • Une image de partage optionnelle pour chaque page actualité, événement, etc.

Conclusion

Une image par défaut au niveau du site, envoyée par le back-office Osuny, permet de laisser le contrôle éditorial aux personnes en charge de la contribution, et de bénéficier du CDN pour générer les variantes d’images. Les personnes en charge du dev peuvent ensuite choisir en configuration d’utiliser l’image ou pas pour les posts et les events.

En ce qui concerne le partage, il paraît raisonnable d’utiliser l’image par défaut pour le partage de la page d’accueil, si elle n’a pas d’image à la une. Cela permet d’avoir une image qui représente le site dans son ensemble. En revanche, pour le partage de toute autre page (article, événement, etc.) sur le site, il paraît plus sain de ne pas mettre d’image s’il n’y en a pas plutôt que d’utiliser l’image par défaut.

Dans le futur, si la réalité l’exige, peut-être faudra-t-il affiner la définition des images par défaut, notamment de distinguer celles utilisées pour éviter les “dents creuses” des articles sans images de celles utilisées pour le partage sur des réseaux sociaux. Il sera peut-être également nécessaire de proposer des images distinctes par type d’objet (une image par défaut de page, une image par défaut de post…), et de proposer une image dédiée au partage pour chaque contenu, comme la meta description.