SPIP 1.9 introduit une collection de filtres graphiques :
— la création d’images typographiques, c’est-à-dire d’images représentant du texte avec la police de caractères de son choix,
— la possibilité d’utiliser une couleur extraite d’une image et de l’appliquer à d’autres éléments de la page ;
— l’application d’effets graphiques sur les images (modifier les couleurs, passer en noir et blanc, en sépia, faire tourner l’image, la découper, la flouter, etc.).

Si vous suivez les présents trucs et astuces, vous avez constaté qu’il s’agit d’un champ d’expérimentation qui me passionne. Cependant, il me semble intéressant de développer la raison pour laquelle ces filtres sont importants ou, dit autrement, pourquoi ils me sont devenus indispensables lorsque je développe un site sous SPIP.

De nouvelles possibilités graphiques ?

Une façon d’aborder ces filtres est de les considérer comme une simple série de nouveautés offertes au créateur de l’interface. SPIP évolue en permanence et s’enrichit ainsi régulièrement de nouveaux outils pour les webdesigners.

Je pense cependant qu’il faut considérer ces filtres d’une autre manière : c’est le rapport entre le webdesigner et les utilisateurs (rédacteurs, client...) qui change, ce qui est beaucoup plus profond.

On peut presque considérer qu’il n’y a pas réellement de nouvelles possibilités graphiques : créer des images typographiques très travaillées (réalisées avec Photoshop ou Gimp) se faisait déjà auparavant, installer des images retravaillées selon la charte graphique du site également. Il était ainsi fréquent d’utiliser les logos et les logos de survol pour installer ce type d’éléments, ou de recourir aux documents joints.

L’évolution, ici, consiste à automatiser des tâches qui était réalisées exclusivement par le graphiste. On livrait le site avec ses squelettes et, essentiellement, un travail graphique relativement fin sur les éléments principaux du site (images typographiques pour les principales rubriques, etc.). En revanche, dès lors que l’on n’était pas l’unique rédacteur de son propre site, on évitait de demander aux autres rédacteurs de réaliser de tels effets.

Utiliser les images des rédacteurs

Pour le dire brutalement : on livrait un graphisme soigné pour l’interface générale du site, on installait un graphisme pour les principales rubriques, mais pour le reste on excluait systématiquement les images installées par les rédacteurs de l’interface graphique : les automatismes utilisaient les éléments textuels pour la navigation (afficher le titre et le descriptif du dernier article sur la page d’accueil, par exemple), mais on n’intégrait quasiment pas les logos et documents joints installés par les rédacteurs ailleurs qu’en « illustration » sur la page de l’article, craignant qu’une image mal choisie, aux couleurs inadaptées, aux dimensions peu utilisables, ne vienne rompre la belle cohérence graphique que l’on avait mise en place.

La version 1.7 de SPIP avait commencé à permettre d’ouvrir un peu plus l’interface graphique aux images installées par les rédacteurs grâce au filtre |reduire_image qui, déjà, garantissait une certaine cohérence :
— en limitant la taille des vignettes (éviter de faire « exploser » l’interface avec des images trop grandes) ;
— en favorisant des alignements de vignettes en forçant la largeur ou la hauteur.

Les nouveaux filtres poussent cette logique beaucoup plus loin. On peut désormais intégrer à l’interface graphique les images des rédacteurs en leur faisant adopter des caractéristiques graphiques respectant la cohérence graphique de manière spectaculaire : image recadrées, « typage » graphique très impressionnant. Par exemple : imaginons une interface de page d’accueil où tous les logos d’articles sont recadrés en carré et passées en noir et blanc ; avec les nouveaux filtres, on ne s’est pas contenté d’éviter de faire « exploser » l’interface avec des images mal dimensionnées, mais on les a surtout utilisées pour contribuer à la charte graphique très typée du site. Au lieu de tout faire pour se prémunir des erreurs graphiques des rédacteurs, on utilise l’outil pour les mettre en avant en les adaptant à la charte.

Voici une situation, à laquelle j’ai été confronté, qui montre une utilisation de cette logique : pour un portfolio de photographies d’architectures, j’ai installé des vignettes de petite taille pour assurer la navigation ; réduites et recadrées, ces petites vignettes semblaient un peu « fades ». L’application d’un filtre de « saturation » m’a permis, de manière automatique, de renforcer la « chaleur » des couleurs. Il est intéressant de noter que l’utilisation du filtre est ici extrêmement discrète : si je ne le dis pas, je peux supposer que personne ne se doutera de l’application d’un tel filtre sur de petites vignettes ; cependant cela améliore beaucoup la qualité de mon interface graphique, et je peux mettre en avant les images, qu’une série de filtres a rendues plus adaptées.

Cette étape est déjà, pour moi, vitale : les images installées par les rédacteurs (ou le client) peuvent désormais être bien plus utilisées (et mises en avant) dans l’interface générale du site alors qu’auparvant, on tentait surtout de les cacher... Le site devient ainsi graphiquement plus vivant.

Réaliser des effets impossibles à confier aux rédacteurs

Cette mise en avant des éléments graphiques installés par les rédacteurs est renforcée par le fait qu’on peut appliquer aux images des traitements réellement impossibles à confier à des utilisateurs sans compétences graphiques.

Ces traitements seraient longs (et donc coûteux) si on demandait à un graphiste d’enrichir l’interface à chaque article publié, par ailleurs il n’est absolument pas possible de les confier à des rédacteurs ne maîtrisant pas de manière poussée les outils tels que Photoshop ou The Gimp.

Par exemple, il ne serait pas imaginable de demander aux rédacteurs de créer, pour chaque article proposé, une image typographique telle que celle-ci et de l’installer en logo d’article. Et il est difficile de proposer qu’un graphiste professionnel intervienne à chaque parution d’article pour le faire...

Pour pousser encore l’exemple, il semble évident qu’on ne pourra jamais demander à des rédacteurs de réaliser eux-mêmes des retouches telles que celle-ci (désaturer toutes les couleurs sauf le rouge) :

Automatiser la création des éléments d’interface

L’un des aspects qui évolue énormément avec ces nouveaux filtres est la création des éléments de navigation de l’interface graphique (boutons, vignettes...).

Ces éléments eux-mêmes, généralement très typés pour un site Web, peuvent désormais être créés automatiquement. De fait, les informations apportées par les rédacteurs sont utilisables pour créer ces éléments de navigation.

On pense en premier lieu aux logos permettant de pointer vers les articles, mais aussi aux vignettes de navigation dans un portfolio. Notre exemple d’images « timbrées » est destiné, typiquement, à créer des éléments de navigation :

On voit d’ailleurs ici que le fort typage graphique minorera grandement les éventuelles imperfections de l’image installée par un rédacteur : une image pas très belle deviendra un timbre très acceptable (même si, comme le savent les graphistes : « Shit in, shit out »).

J’utilise aussi les images typographiques pour réaliser certains éléments de navigation (par exemple, un bandeau de navigation de navigation en haut de page, présent sur toutes les pages, avec les titres affichés dans une police de mon choix, de petite taille).

L’extraction de couleurs relève d’une logique similaire : faire vivre l’interface graphique d’une page à l’autre grâce aux éléments installés par les rédacteurs, mais en garantissant une grande cohérence graphique dans la palette utilisée.

La création d’une palette de couleurs basée sur la roue chromatique va dans ce sens.

Quant aux filtres sur les images, la création de vignettes plus ou moins typées est, comme nous l’avons vu, un usage assez évident. Notons de plus que ces filtres deviennent à l’usage incontournables pour créer automatiquement des variantes pour les survols des vignettes. Dans l’exemple précédent de mes petites vignettes de navigation dans un portfolio d’architecture, je créé ainsi une version en noir et blanc, légèrement foncée, pour marquer la vignette de la photographie actuellement affichée, et encore une variante pour le survol de la souris au-dessus des vignettes. La case « logo pour survol » de l’interface privée devient rigoureusement inutile : l’image pour le survol étant créée automatiquement par le squelette.

La logique du CMS appliquée aux images

J’ai jusqu’ici insisté sur l’impossibilité de demander aux rédacteurs d’appliquer certains effets (ce qui demanderait de bonnes compétences graphiques), ou sur le temps perdu pour faire travailler un graphiste à chaque nouvelle mise en ligne.

En réalité, il faut aller plus loin : il ne faut pas que l’interface graphique soit gérée depuis l’espace privé, il ne faut jamais installer, dans la base, d’images graphiquement typées dans le système pour réaliser l’interface graphique.

Je m’explique. Pour un site, la navigation dans le portfolio se fait avec des vignettes très typées : elles sont d’une certaine taille, et présentent un reflet qui suggère que l’image est posée sur un sol transparent. J’ai déjà présenté un effet similaire avec du texte texturé :

Comme je l’ai dit, il semble évident qu’on ne pourra pas demander aux rédacteurs de créer une telle version de leur image pour chaque article (pas assez compétent avec Photoshop et The Gimp, et perte de temps énorme) ; il faut surtout comprendre que même si c’était faisable, il ne faudrait pas le faire ! Si, dans quelques temps, on voulait modifier la charte graphique du site, on serait lié à des images très typées réalisées précédemment. Si, au lieu de présenter des vignettes se reflétant au sol, on voulait des vignettes plus grandes en noir et blanc et avec les coins arrondis, cette façon de procéder obligerait à reprendre tout le site !

Il est donc indispensable de considérer que ces effets de typage des images doivent être réalisés par des automatismes : on installe et on conserve dans le système l’image d’origine, et c’est le squelette qui applique la charte graphique.

Ainsi, clairement, les images deviennent des éléments qui rejoignent les éléments textuels dans la logique du CMS : séparer le contenu de la forme et de l’interface.

De plus en plus d’outils de création de sites Web proposent la possibilité d’appliquer des traitements graphiques aux images (par exemple iWeb d’Apple permet de passer une image en noir et blanc, en sépia, de renforcer les constrastes, etc.). Mais ces traitements sont proposés directement au rédacteur lors de la création de son document. Le raccourci et la liberté peuvent séduire, mais à mon avis constituent une erreur : tout l’intérêt d’une gestion de site, de type CMS, consiste justement à ce que ce soit un automatisme qui fabrique l’interface graphique, et non le travail individuel et ponctuel de chaque rédacteur. Non seulement pour le gain de temps, mais surtout pour garantir les possibilités d’évolution de l’interface par la suite (et, d’expérience, je peux garantir que tout site, même de grande qualité, a besoin d’un lifting graphique au bout de quelques années).

* * *

J’espère que ces quelques considérations aideront les créateurs de site (graphistes et webmestres) à utiliser ces nouvelles possibilités non pas comme de simples gadgets techniques, mais en modifiant plus profondément leur rapport avec le contenu installé par les rédacteurs.

Utilisant ces filtres depuis quelques mois, je peux affirmer qu’il y a là un très important changement dans la façon d’utiliser les informations de la base de données (ici les images), et de les mettre en valeur sur le site. C’est à la fois passionnant pour le webdesigner, gratifiant pour les rédacteurs (qui voient leurs images utilisées de manière beaucoup plus importante dans l’interface graphique) et agréable pour les visiteurs qui consultent des sites dont le graphisme intègre plus d’éléments changeant au cours du temps et de la navigation.

Il y a de plus une évolution consistant à rapprocher les compétences graphiques et techniques : si, souvent, on confiait le graphisme à un graphiste, puis l’intégration (création des squelettes) à un technicien, la meilleure utilisation de ces nouvelles possibilités demande un rapprochement beaucoup plus étroit de ces compétences : le graphiste doit, au minimum, bien connaître et pouvoir expérimenter toutes ces possibilités. Idéalement : le graphiste développe des compétences techniques (ce que l’on a vu, déjà, pour les feuilles de style et, assez souvent, pour Flash).

Le graphiste, de plus, doit changer sa façon d’apporter une solution graphique à son client. Que ce soit en PAO ou sur support informatique, il avait jusqu’ici l’habitude de prendre en charge la réalisation complète du graphisme ; et s’il livrait un « fond de page », il était évident que toute opération graphique serait au moins réalisée par un autre graphiste (qui, lui, se contenterait d’appliquer la charte ainsi définie). Désormais, il doit penser ses solutions graphiques selon une série d’automatismes, c’est-à-dire analyser la série d’opérations à réaliser pour obtenir le résultat graphique, sachant que ce sera un logiciel (SPIP) qui les appliquera de manière totalement automatique. Cette logique est déjà visible dans les templates livrés par Apple dans ses logiciels grand public (Page, Keynote, iWeb) ; mais là où ces outils ne permettent pas aux graphistes tiers de livrer leurs propres templates, cette possibilité est désormais au centre du travail du webdesigner utilisant SPIP.

Un dernier mot pour dire du mal du W3C (c’est mon dada) : de la même façon que la présentation du texte profite de traitements par feuille de style, les images elles-mêmes devraient relever de styles graphiques. Les filtres de SPIP pallient ce qui m’apparaît un manque important : la séparation entre le fond (l’image d’origine, peu typée graphiquement) et la forme (l’interface graphique, très typée et cohérente). Que seul Microsoft ait commencé l’intégration de tels « filtres » (et, évidemment, à la sauce Microsoft) permettant de traiter le graphisme des images via des styles CSS est assez scandaleux.