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) :

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 : 1/ La structure d'une page. 2/ Les éléments d'une page. 3/ La charte graphique.

Ceci est le second 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.

Dans l'article précédent, nous avons vu qu'une page Drupal se découpait en régions. Les régions sont des contenants aptes à accueillir différents éléments d'information. Ces derniers sont fort variés et doivent être considérés lors de l'élaboration d'une charte graphique. Je vais tenter d'en faire l'énumération :

Éléments de contenu :

• Noeuds : Ces éléments sont typiquement créés et modifiés par des utilisateurs du site. Différents types de noeuds sont possibles, par exemple : articles, nouvelles, billets, évènements, fiche de membre, notice bibliographique, etc. Chaque type de noeud comporte ses propres champs, par exemple : titre, corps, auteur, date de création, date d'évènement, adresse, code ISBN, etc. L'éventail de types de noeuds de même que le détail des champs est hautement personnalisable; chaque projet définira ceux qui sont requis. Sur le plan du design, il sera nécessaire d'établir comment seront présentés chacun des éléments d'information. Le noeud est la principale unité de contenu sous Drupal et l'essence d'un site basé sur Drupal tourne autour de la manipulation des noeuds. Le coeur de la plupart des pages est constitué soit d'un noeud, soit d'une liste de noeuds (ou vue). Une vue présente des champs de noeuds choisis selon certains critères (par exemple : une en ordre chronologique montrant le titre et l'auteur de tous les noeuds classés dans une catégorie « design »). Lorsqu'une page contenant une vue est demandée par un visiteur, le système recueille et présente dynamiquement tous les noeuds correspondant aux critères associés à cette vue. Encore une fois, le designer a donc affaire à du contenu dynamique.
• Blocs : Les blocs sont des éléments d'information qui, généralement, servent à offrir l'accès à différentes fonctionnalités du site ou à offrir un complément d'information relatif au noeud (ou à la vue) présenté dans la page. Les blocs sont créés par des utilisateurs, contiennent une vue sur plusieurs noeuds, ou sont générés par différents modules du système. Comme les noeuds, les blocs sont hautement dynamiques et contextuels. Les blocs sont positionnés dans des régions par les administrateur du site et certains blocs n'apparaissent que dans certaines pages ou à certains utilisateurs. Par exemple, le bloc de connexion montre un formulaire où entrer un identifiant et mot de passe, mais disparaît une fois la connexion établie. Sur drupal.org, la table des matières d'une page de documentation n'apparaît que lorsque l'une des pages du manuel est visitée.

Éléments de navigation :

• Menus : Les menus sont généralement le principal outil de navigation du site. Ceux-ci sont également dynamiques, puisque leur contenu exact peut varier selon le contexte et les droits d'accès de l'utilisateur. Les menus sont positionnés dans des régions et peuvent prendre différentes formes selon le contexte et le design souhaité : listes de liens, listes déroulantes, onglets.
• Fil d'Ariane : Un outil d'aide à la navigation fréquemment offert, le fil d'Ariane est généré automatiquement par Drupal afin de présenter une piste du chemin parcouru par le visiteur pour atteindre la page courante.
• Pagination : La pagination permet de naviguer dans des listes d'éléments (noeuds ou autres) réparties sur plusieurs pages. Quelques exemples d'éléments communément utilisés dans la pagination : liens vers la première et la dernière page, liens vers la page précédente et la suivante, indication de la page courante, nombre total d'éléments, etc.
• Informations de publication : Un noeud est souvent accompagné de certaines métadonnées, telles que son auteur et sa date de publication. Ceci est tout à fait analogue à un champ, mais la présentation en est souvent distincte. En outre, il peut s'agir d'un élément de navigation, puisque le nom de l'auteur est couramment offert comme un hyperlien vers un profil de membre.
• Liens contextuels : Un noeud est fréquemment accompagné de liens contextuels, par exemple : lien donnant accès au texte intégral, lien vers un fichier joint, lien pour ajouter un commentaire.
• Catégories : Beaucoup de sites présentent des listes de catégories associées à chaque noeud en guise d'outil de navigation supplémentaire, une fonction offerte par Drupal à la base.

Éléments d'interface :

• Messages : Les messages sont produits par le système pour fournir des informations utiles au visiteur. Deux types de messages sont produits : messages d'information et messages d'erreur. Plusieurs messages peuvent être présentés simultanément, auquel cas une liste HTML est utilisée comme contenant.
• Formulaires : Pratiquement tous les sites comportent des formulaires permettant aux utilisateurs de saisir des informations, par exemple : formulaire de connexion, formulaire de contact, formulaire de commentaire, demande d'adhésion au site. Une variété d'éléments graphiques sont à prévoir dans un formulaire : Champ (texte, liste, liste déroulante, bouton radio ou case à cocher), titre de champ, description de champ, bouton, indicateur de champ obligatoire, regroupement de champs (ouvert ou fermé). À noter qu'un message est généré lorsqu'une erreur de saisie est faite dans un formulaire, tandis que les champs erronés sont soulignés de manière plus visible.

Voici un aperçu de quelques-uns des éléments mentionnés ci-dessus :

Légende :

Et voici un exemple de formulaire accompagné d'un message d'erreur :

Bien entendu, la plupart des sites quelque peu avancés comporteront des éléments supplémentaires; un calendrier ou un système d'évaluation (vote) des contenus sont des cas fréquents. J'ai tenté ici d'énumérer les éléments communs à presque tous les sites Drupal. Ces éléments devraient toujours faire l'objet d'une réflexion de design — et bien sûr, on peut par cette réflexion décider d'en omettre quelques uns ou d'altérer grandement leur apparence de base!

Drupal offre une pleine latitude sur la forme de ces éléments. Une critique souvent entendue est que beaucoup de sites Drupal se ressemblent, une situation que je dois admettre comme plutôt vraie. Cependant, ceci s'explique de deux ou trois façons, soit un faible investissement en conceptualisation graphique ou, tout simplement, l'omission par le designer prendre tous les éléments en considération. En outre, il arrive que l'intégrateur graphique ou le programmeur ne sache pousser la machine à fond, faute de connaître suffisamment la plate-forme (Drupal est encore nouveau pour un grand nombre de professionnels). Au final, les éléments graphiques qui ont été omis lors du design ou de l'intégration héritent tout simplement de la forme par défaut proposée par Drupal.

Nous avons maintenant les outils nécessaires pour développer la charte graphique, sujet de l'article suivant.

Tous les articles de la série : 1/ La structure d'une page. 2/ Les éléments d'une page. 3/ La charte graphique.

Ceci est le premier 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.

Un système de gestion de contenu tel que Drupal offre aux utilisateurs d'un site Web un plein contrôle sur les contenus. Différents utilisateurs jouent différents rôles sur le site, qu'il s'agisse de l'administration, de la modération, de la rédaction, de la révision ou de la traduction des contenus, ou tout simplement de la rédaction de commentaires rattachés aux contenus (comme dans le cas d'un blogue ou d'un forum de discussion, par exemple). Les contenus sont créés et gérés directement sur le système, souvent par des individus ayant peu de connaissances techniques, sans qu'il ne soit nécessaire d'utiliser un logiciel tiers ou de faire appel à un designer ou un technicien.

Ainsi, les contenus sont extrêmement dynamiques, grandement hors du contrôle du designer. Non seulement les contenus sont-ils hautement variables, mais les contrôles d'accès font en sorte que différentes fonctions du système et différents contenus seront exposés à différents utilisateurs selon les accès autorisés à chacun, ce qui affecte également l'apparence des pages présentées aux internautes.

Ce dynamisme amène la nécessité de concevoir la structure des pages non pas en fonction de contenus spécifiques, mais plutôt en fonction de différentes régions qui contiendront des contenus, sans connaissance préalable de la nature exacte des contenus. Chaque région devient en quelque sorte un mur accueillant une ou plusieurs oeuvres (contenus), ajoutés, supprimés ou modifiés au fil du temps. La région elle-même prend place dans une page, à la manière d'une salle dans un musée. Bref, suivant cette métaphore, le site est comme un musée renfermant plusieurs salles (pages), elles-mêmes pourvues de murs (régions), auxquels se rattachent plusieurs oeuvres (contenus).

Voici un schéma des régions (en rouge translucide) utilisées sur une page du site drupal.org :

Il est possible de créer autant de régions que requis par le design et de leur assigner différents éléments, ce qui permet à différents sites d'adopter des structures plus ou moins complexes. En outre, certaines régions peuvent apparaître seulement lorsqu'elles contiennent des éléments, comme c'est le cas de la colonne de gauche (numéro 2 ci-dessous) dans une page de documentation de drupal.org :

Les régions sont l'une des principales unités de structure d'une page. L'article suivant aborde les autres types d'éléments que comporte la page.

Tous les articles de la série : 1/ La structure d'une page. 2/ Les éléments d'une page. 3/ La charte graphique.

Pour de la documentation plus technique liée à la création d'un « thème » Drupal, le lecteur peut se référer à d'autres ouvrages, tels le Theme Developer's Guide ou l'excellent chapitre 8 du livre Pro Drupal Development.

2007-11-22 — mise à jour : Merci à Patrick Fournier pour la métaphore du musée, plus visuelle et plus claire que la précédente!

Gérer le courriel, c'est l'enfer... J'aime bien tout classer, mais je ne veux plus glisser-déposer manuellement des messages dans des dossiers. Quelle plaie que de défiler parmi des dizaines de dossiers pour déposer un message au bon endroit! Et je ne veux plus être contraint à gérer une hiérarchie unique de dossiers. Il y a toujours de ces messages qui entreraient dans plus d'une catégorie.

Vivement l'étiquetage libre, le tagging! Et je ne parle pas de la tristounette fonction de tagging de Thunderbird 2.0, qui ne va vraiment pas assez loin. Non, mon client courriel idéal aurait les caractéristiques suivantes :

• Opération entièrement via le clavier.
• Possibilité d'associer des étiquettes (tags) à chaque message via la saisie des termes, simplement via un champ texte (plutôt qu'une fastidieuse sélection via la souris). La complétion automatique à partir d'étiquettes existantes rendrait cette fonction encore plus rapide.
• Lors de la composition d'un courriel, avoir la possibilité de l'étiqueter.
• Sur réception d'une réponse à un courriel antérieur, associer par défaut les mêmes étiquettes que le message original,
• Aucun dossier! Courriels entrants, sortants, brouillons, pourriels seraient tous au même endroit.
• La magie tiendrait dans le filtrage des courriels selon les étiquettes ainsi que d'autres critères de recherche au choix. On pourrait facilement combiner plusieurs étiquettes ou critères via des opérateurs booléens.
• Le filtrage serait incrémental (interactif), dès qu'on saisit des critères. Nul besoin d'un bouton « soumettre ».
• Possibilité de créer plusieurs vues simultanées sur la boîte à malle, chaque vue utilisant son propre filtre.
• Des opérations de masse (destruction, étiquetage, etc) pourraient être exécutées sur les courriels filtrés.
• Outils d'automatisation de l'étiquetage selon différents critères (de la même manière que la plupart des clients permettent de marquer, effacer ou déplacer des messages actuellement).
• Outils d'annotation et de surlignage de messages.

Oui, bien sûr, GMail et autres clients similaires favorisent la recherche plutôt que le fastidieux classement dans des dossiers, mais pour moi ça ne gère pas bien les cas où on ne sait pas très précisément ce qu'on recherche et où le texte des messages ne contient pas les mots-clés utilisés dans notre recherche. Des métadonnées de classement pourraient aider dans ce cas, elles permettraient de naviguer dans les messages et non seulement de rechercher.

Débarrassez-moi de la hiérarchie de dossiers!

Il semble que l'outil dont je rêve aurait certaines ressemblances avec del.icio.us, mais pour gérer des courriels au lieu d'hyperliens. Connaissez-vous un lecteur de courriels qui possède ce genre d'interface? Si oui, faites-le moi connaître! :-)

Le fondateur du Cirque du Soleil, Guy Laliberté, a récemment créé, avec plusieurs partenaires, une fondation visant à assurer l'accès à l'eau potable aux population des pays en développement : la Fondation One Drop.

Le site Web de la Fondation, www.onedrop.org, qui vient d'être lancé, est basé sur Drupal.

Voilà un cas de site intéressant à analyser...

Sur le plan de l'interface utilisateur, à mon point de vue la facture visuelle est très réussie. Également, la navigation animée (via Flash) est fort intéressante et nous donne envie de cliquer sur chacun des liens. Mais voilà, justement, la navigation nous captive peut-être au point de nous distraire des contenus? D'ailleurs, le fait de devoir attendre la fin d'une animation pour obtenir la page demandée suit le même mode de fonctionnement que la « splash page », cette affligeante pratique qui consiste à montrer une animation à l'entrée d'un site avant d'amener le visiteur au contenu qu'il désire consulter.

Sur le plan technique, tout de même, les concepteurs du site semblent avoir bien compris que, pour assurer un référencement et une accessibilité adéquats, il ne fallait pas articuler un site Web autour de Flash, mais plutôt utiliser Flash (si on y tient — voilà autre débat) pour enrichir l'expérience du visiteur. Ici, l'élément Flash est techniquement accessoire, puisque chaque contenu possède sa propre adresse (URL) et est présenté en HTML, assurant son accessibilité. Bon point.

Malheureusement, un petit détail technique a été manqué puisque certains hyperliens appartiennent à l'objet Flash, tandis que d'autres sont statiquement codés dans le HTML pour lancer des instructions JavaScript (servant à lancer l'animation Flash et à charger la page demandée après l'écoulement du délai d'animation). Les premiers sont absents si l'extension Flash n'est pas installée dans le navigateur, Les seconds ne fonctionnent pas si le navigateur est dépourvu de JavaScript. La plupart des robots sont incapables de parcourir ces types de liens. Si ce n'était de ce petit détail, si le paradigme de JavaScript discret était strictement appliqué, le site pourrait être entièrement parcouru par n'importe quel navigateur Web ou robot, qu'il soit ou non doté de JavaScript et Flash. Drupal implémente et prône pourtant ces pratiques exemplaires, c'est donc un peu dommage qu'une autre voie ait été empruntée. À notre époque où toutes sortes de plate-formes hétéroclites sont utilisées par les internautes, favoriser l'accessibilité est indispensable.

Voilà pour la petite analyse de fin de soirée... J'espère ne blesser personne par ces quelques observations. J'y ai simplement trouvé un prétexte pour évoquer quelques enjeux en conception Web au sujet desquels je souhaitais bloguer depuis un bon moment déjà. Ma première impression du site fut pourtant extrêmement favorable et, avant de me mettre à écrire ces lignes, c'est plutôt en tant que beau modèle de site Drupal que je comptais le présenter!

Chose certaine, je souhaite à la Fondation le meilleur des succès dans l'atteinte de ses nobles objectifs!

Les utilisateurs de Drupal ont sans doute déjà lu ce nom à maintes reprises: Dries Buytaert. Fondateur et leader du projet Drupal, ce formidable rassembleur et architecte logiciel visionnaire sera de passage à Montréal entre les 21 et 25 octobre prochains. Et curieusement, il ne sera pas ici pour parler de Drupal, mais de Java! En effet, il effectuera deux présentations concernant des techniques d'évaluation et d'optimisation de la performance de systèmes Java, dans le cadre de la conférence ooPSLA 2007 organisée par l'ACM SIGPLAN.

La communauté Drupal montréalaise aura peut-être l'occasion de le rencontrer... À suivre!