Publié le

Ceci est le dernier d’une série de trois articles à travers lesquels j’explore les principales particularités de Drupal auxquelles doit faire face un designer graphique. Ceci s’adresse non seulement aux designers, mais également aux intégrateurs et programmeurs qui souhaiteraient communiquer quelques trucs à leurs équipes afin de créer des concepts graphiques bien adaptés à la plate- forme et, en même temps, réalisés plus rapidement. Ces articles seront particulièrement utiles aux designers ayant peu ou pas d’expérience avec des systèmes de gestion de contenus. Toutefois, j’ose croire que tout le monde pourra y trouver son compte, ne serait-ce que pour formaliser quelques idées. Un seul pré-requis : Avoir déjà conçu ou intégré un design Web.

Maintenant que nous connaissons la structure et les principaux éléments d’une page Drupal, le temps est enfin venu d’élaborer la charte graphique!

Puisque les contenus et éléments apparaissant dans une page sont hautement dynamiques, il est impossible de prévoir d’avance la teneur exacte d’une page. Par conséquent, il convient de penser la charte graphique d’un site dynamique en termes de normes graphiques applicables à une variété de contextes, un peu à la manière d’un cahier de normes graphiques pour une grande organisation. Bien sûr, l’on souhaite que la charte graphique inclue les maquettes des pages clés du site (notamment la page d’accueil), mais l’intégrateur aura surtout besoin de normes qu’il pourra appliquer aux différents éléments d’une page et qui pourront par la suite s’agencer dans une multitude de combinaisons (prévues ou non au moment de la conception graphique).

Lorsque les maquettes remises à l’intégrateur graphique sont conçues pour une structure fixe et un contenu pré-établi, l’intégrateur est confronté à plusieurs problèmes. Une telle maquette ne révèle ni la logique ou la réflexion ayant guidé les choix du designer, ni l’ensemble des éléments pouvant constituer une page générée dynamiquement ou altérée par l’interaction de l’utilisateur avec le système. Que survient-il si tel contenu vedette de la page d’accueil n’est pas accompagné d’une illustration tel que sur la maquette? À quoi doivent ressembler les sous-titres, si un éditeur en introduit dans un article? Qu’en est-il des tableaux et des listes numérotées? Peut-on ajouter un nouvel élément au menu sans casser le design? Où placer les menu d’administration du site qui ne sont pas visibles aux visiteurs normaux? Que fait-on avec les messages d’erreur? À quoi ressemblera la pagination si un grand nombre d’articles est ajouté? Que fait-on de la boîte « évènements à venir » lorsqu’elle est vide parce qu’aucun évènement n’est prévu? Comment adapter l’interface aux libellés plus longs de l’autre langue utilisée sur le site? Telles sont des questions typiques que posera l’intégrateur graphique.

En vue de créer une charte graphique adaptée aux systèmes de gestion de contenu — Drupal en particulier — je propose de l’articuler autour de quatre volets :

  • La plastique des pages.
  • Les normes graphiques générales.
  • Les normes graphiques spécifiques.
  • Les maquettes des pages clés du site.

La plastique des pages

Cette première section de la charte graphique présente les éléments structuraux requis par les différentes pages du site, sous forme schématique. À la différence du schéma wireframe typiquement produit pendant la phase d’architecture du site, plutôt que de procéder à l’identification des éléments de contenu, il s’agit ici de définir une structure sur laquelle reposeront les règles stylistiques.

Une notion essentielle à ce stade-ci consiste à identifier les zones à taille fixe et les zones « fluides » (à taille variable) de chaque modèle de page. La fluidité est une propriété fondamentale de la page Web suivant les normes XHTML et CSS, puisqu’on ne contrôle ni la taille de la fenêtre du fureteur, ni la taille et les caractéristiques exactes de la typographie. Soyons clairs : À moins d’avoir affaire à un élément de taille absolue tel une image, un extrait vidéo ou un objet Flash, tout élément possède une taille variable! Un titre qui entre sur une ligne chez un internaute pourrait très bien en exiger trois chez un autre.

La taille des éléments étant affectée par l’environnement dans lequel la page est visualisée, le design doit donc intégrer l’expansion et la contraction des différentes zones sur au moins sur l’axe vertical, sinon sur les deux axes (vertical et horizontal). Embrasser cette contrainte procure un double avantage : Non seulement la page devient-elle lisible sur un grand nombre de périphériques, aussi peut-elle accommoder les fréquentes modifications de contenus inhérentes à un système de gestion de contenu.

Voici un exemple illustrant cette notion. L’orientation du dégradé vert indique l’axe d’expansion ou de contraction (un dégradé en diagonale dénote une fluidité sur les deux axes), tandis que le rouge désigne une zone dont la taille est fixe sur les deux axes (tout contenu de taille excédentaire pourrait alors être tronqué ou empiéter sur d’autres zones) :

Fluidité des éléments d'une page de drupal.org

L’observateur averti pourra constater dans cet exemple une erreur de design (sans doute un compromis, en fait) : Les onglets et la boîte de recherche sont à taille verticale fixe, de telle sorte que ces zones ne peuvent accommoder une taille de caractères tellement différente (en hauteur) de celle espérée par la feuille de style du site.

Les normes graphiques générales

La seconde section de la charte graphique donne les principes généraux de la signature visuelle du site, ainsi que l’apparence par défaut de tous les éléments primitifs, notamment :

  • Paragraphes — (comme pour tous les autres éléments de forme textuelle de la présente liste, les propriétés suivantes peuvent être prises en considération : marges, justification, police, taille, graisse, interlignage, crénage, couleur du texte, couleur du fond, filet.
  • Titres et sous-titres — potentiellement jusqu’à six niveaux.
  • Listes numérotées et non numérotées.
  • Tableaux — incluant les en-têtes.
  • Citations, définitions, extraits de code.
  • Hyperliens — incluant les états : normal, courant (présentement visité), déjà visité, survolé par la souris, sélectionné au clavier.
  • Images — penser à : taille, marges, alignement, filets, légende, comportement du texte autour de l’image.
  • Boutons — incluant les états : normal, pressé, survolé par la souris, sélectionné au clavier.
  • Champs de formulaires — incluant les états : normal, erroné, courant (présentement manipulé), ainsi que leurs attributs (libellés et descriptions).

Ces éléments correspondent directement à des balises XHTML, mais j’ai également inclu quelques états et attributs qui sont presque aussi fondamentaux sous Drupal.

Les normes graphiques spécifiques

La troisième section de la charte graphique prescrit l’apparence des éléments primitifs dans différents contextes, lorsqu’elles diffèrent des normes graphiques générales. On peut varier l’apparence d’un titre, par exemple, en fonction de la page, de la région, du bloc, du noeud, de l’auteur du noeud, ou même d’une catégorie associée au noeud dans lequel ce apparaît ce titre. De cette façon, un site pourrait appliquer un style général aux articles apparaissant dans différentes pages du site, puis un style spécifique lorsque ces articles apparaissent dans la page d’accueil. Sur le même principe, on pourrait accompagner les articles d’icônes distincts selon qu’il s’agisse d’un communiqué, d’un texte de référence ou d’un billet de blogue.

Le nombre et la nature des contextes varie grandement d’un site à l’autre. Tous les éléments primitifs peuvent adopter une apparence propre au contexte auquel ils appartiennent.

Voici quelques exemples de contextes possibles, un contexte étant, finalement, l’un des multiples « contenants » pouvant englober l’élément auquel on cherche à appliquer un style :

  • Page.
  • Région.
  • Bloc.
  • Noeud
  • Menu.
  • Fil d’Ariane.
  • Pagination.
  • Informations du publication.
  • Liens contextuels.
  • Catégories associées au noeud.
  • Message informatif ou message d’erreur.
  • Élément identifié.
  • Balise XHTML.

Bien sûr, cette liste n’est pas exhaustive, puisque chaque projet a l’opportunité d’ajouter ses propres éléments ou contextes.

Plusieurs de ces contenants s’emboîtent comme des poupées russes; il est donc possible de tirer parti de combinaisons pour appliquer un style. Concrètement, ceci signifie qu’un design pourrait, par exemple, prescrire la règle générale d’afficher les hyperliens en bleu avec soulignement, tandis que ceux-ci seraient verts dans le contexte d’un bloc situé dans la région A, jaunes dans la région B et sans soulignement dans le contexte d’un menu. On peut définir des règles plus ou moins spécifiques comme, par exemple : Tous les boutons sont rouges, sauf le bouton « Rechercher » de la page d’accueil qui est vert. L’idée maîtresse est de penser le design en fonction de classes d’éléments plutôt qu’en fonction d’occurences singulières de ces éléments, puisque ces occurences sont particulièrement éphémères dans un système de gestion de contenu.

Il s’agit d’éviter les situations où aucune règle d’application de style ne peut être établie en fonction des contenants disponibles! Si, par exemple, la couleur rose était affectée à un paragraphe de manière purement arbitraire, cette propriété ne serait applicable qu’à l’aide d’un éditeur WYSIWYG, ou manuellement en modifiant directement le contenu en XHTML. Dans les deux cas, l’on retirerait à la feuille de style du site son rôle de maître de la présentation et déleguerait une partie de ce rôle aux rédacteurs ou intégrateurs du site. Le dynamisme des contenus fera en sorte que, inévitablement, la règle de style irrégulière deviendra rapidement caduque ou mal appliquée (nuisant à la cohérence visuelle du site); les rédacteurs auront de la difficulté à l’appliquer s’ils n’ont pas les ressources ou les connaissances techniques pour le faire. Tout attribut de style qui ne puisse être appliqué par une règle automatique et qui complique la rédaction des contenus devient un élément dissuasif à la création et à la mise à jour des contenus, ce qui, forcément, est à éviter!

Lorsque des éléments semblent manquants pour arriver à établir les règles d’application de styles nécessaires à la réalisation d’un certain concept visuel, généralement il suffira d’une discussion entre designer, intégrateur et/ou programmeur pour rapidement définir une solution.

Enfin, un bon truc pour aider le designer à identifier les éléments, les contextes, ainsi que les règles possibles consiste à lui fournir un prototype du site. En effet, un processus de travail fort efficace consiste à, avant que le travail de design graphique ne soit amorcé, d’abord bâtir un prototype fonctionnel (même incomplet) à partir des schémas (wireframes) acceptés par le client, puis de laisser ensuite au designer tout le loisir d’explorer la structure du système. Au besoin, des tests de validation technique pourront même être réalisés directement sur le prototype afin de déterminer la faisabilité de certains concepts visuels ou interactifs plus complexes, et ce avant même de soumettre des maquettes au client.

Les maquettes des pages clés du site

La dernière section de la charte graphique présente un aperçu détaillé des pages clés du site, de manière traditionnelle, c’est-à-dire sous la forme d’un écran pour chaque page — quoique, bien sûr, d’autres formes de présentation sont possible. Ceci permet d’appliquer à des cas concrets l’ensemble des normes graphiques. Le travail même de bâtir les maquettes constitue une occasion de valider les normes.

Bien entendu, la plupart des designers réaliseront des maquettes bien avant de se pencher sur le détail des normes graphiques et de leurs règles d’application! La table des matières de la charte graphique n’a pas à dicter le processus créatif!

Conclusion

Par cette série d’article, j’espère avoir couvert les principales particularités rencontrées lors de la réalisation d’un design graphique pour un système Drupal. J’ai présenté la structure et les éléments d’une page Web générée par Drupal, puis un format de charte graphique ayant pour objectifs, d’une part, l’adéquation du design à la plate-forme à laquelle il est destiné et, d’autre part, la mise en place d’un riche outil de communication utile au designer graphique et à l’intégrateur.

Il est certes très exigeant de construire une charte graphique aussi technique et détaillée que je le propose. À chaque équipe de décider jusqu’où aller en fonction de ses besoins et de ses aptitudes!

Tous les articles de la série :

Commentaires