Drupal

La Fondation de Guy Laliberté utilise Drupal

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!

Sujets: Design · Drupal · Flash · JavaScript

Dries Buytaert de passage à Montréal

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!

Sujets: Drupal · Java · Montréal

Doit-on construire nos applications web avec Drupal?

Ces deux derniers jours, je me suis fait poser deux questions fort intéressantes (et somme toute assez semblables) par deux dirigeants d'entreprises ayant chacune des équipes de programmeurs, et qui évaluent la pertinence d'utiliser Drupal dans certains projets.

  1. «D'après toi, pour notre équipe très habituée (et très performante) à développer et ré-utiliser ses propres solutions de gestion de contenu, serait-il plus pertinent d'aller vers Ruby on Rails ou Drupal?»
  2. «Pourquoi choisir Drupal plutôt que de bâtir directement les applications en PHP? Je comprends que Drupal fournit plein de fonctionnalités, mais PHP également, à travers de nombreuses bibliothèques.»

D'excellentes questions. Puisque je ne suis pas tout à fait certain d'y avoir parfaitement bien répondu, je vais tenter d'y réfléchir encore un peu ici. Je n'ai pas d'expérience pratique de Ruby on Rails, alors il est pour moi plus difficile d'en parler, mais j'ai tout de même l'impression que les deux questions sont proches.

Chose certaine, la réponse à ces questions dépend de la nature du projet à réaliser. Drupal est un logiciel, il fournit des fonctionnalités prêtes à l'emploi pour des non-programmeurs et, par conséquent, des manières de faire, un certain flux de travail. On peut l'enrichir et l'altérer grandement, bâtir des applications qui n'avaient jamais été envisagées par les concepteurs de Drupal, mais si l'on cherche à construire une application possédant un flux de travail complètement différent, ou si l'on effectue le design interactif de ladite application en ignorant la manière de faire de Drupal, on risque de connaître des difficultés. Dans ces deux situations, il pourrait être préférable de choisir un framework plus générique, pourquoi pas Rails ou Symfony?

Là où l'on tire le mieux profit de Drupal, c'est lorsque ses fonctions (ou celles de modules tiers) répondent out-of-the-box à une partie importante de nos besoins. Je suis tenté d'évoquer la classique règle des 80-20: Si Drupal, clé en main, avec des modules tiers, répond à 80% des besoins du projet, on pourra passer 80% du temps total à régler les 20% de personnalisation nécessaires et on aura déjà gagné beaucoup de temps. (Non vérifié scientifiquement!) D'autant plus que les premiers 80% de besoins comblés peuvent l'être par un bon architecte ou intégrateur, permettant aux programmeurs de s'attaquer à d'autres tâches en parallèle.

Un exemple concret

Sous Drupal, tous les contenus possèdent une structure de base commune appelée noeud. La plupart des fonctions de Drupal et de ses modules tiers font affaire avec cette structure commune. En d'autres mots, les modules partagent un langage commun. Un aspect souvent grisant de Drupal, c'est de découvrir ou d'imaginer de nouvelles façons de faire converser différents modules à travers ce langage, le tout sans écrire une seule ligne de code.

Prenons l'exemple d'un site événementiel où l'on souhaiterait décrire la programmation et des conférenciers. Conférences et conférenciers seront des noeuds, respectivement gérés par les modules Event (qui associe une date à un noeud et peut présenter les noeuds dans des calendriers) et CCK (qui permet de créer un noeud sur mesure, avec différents champs particuliers à la description d'un conférencier: nom, affiliation, photo, biographie, publications récentes, hyperlien vers un site web, etc.). Ces deux types de données sont des noeuds, donc je peux facilement les lier via le module Node Reference (fournit avec CCK), qui permet de connecter des noeuds entre eux. J'obtiens un lien de la fiche de conférence vers celle de son conférencier.

Avec Drupal, tout noeud est automatiquement disponible via RSS, au grand plaisir de visiteurs branchés et de sites agrégateurs, qui seront notifiés dès la publication de nouvelles conférences sur le fil de presse.

J'active les commentaires sur les noeuds, ainsi les visiteurs peuvent commenter les conférences et leurs conférenciers... À travers le module Fivestar, je leur permet de voter sur ces mêmes noeuds puis, avec le module Views, je présente dans la page d'accueil le top cinq des conférenciers les mieux cotés par les visiteurs. Views est ce module que je mentionnais récemment et qui peut produire des listes de noeuds suivant une multitude de critères.

J'adjoins le module Signup et les visiteurs peuvent désormais s'inscrire aux conférences et même recevoir automatiquement un rappel par courriel la veille de l'événement.

Voilà, en quelques heures et sans programmation mon projet a atteint ses objectifs, principalement grâce au fait que toutes les composantes ont une langue commune: le noeud. Le reste du temps sera consacré à la personnalisation, dont l'intégration d'un design graphique distinctif.

Avantage supplémentaire: En n'ayant pas écrit une seule ligne de code, je me trouve à bénéficier des entretiens du code et des mises à jour produits par la communauté Drupal. En d'autre mots, je ne prend pas sur mes épaules l'entretien complet du code, la communauté Drupal le fait! Et si par hasard j'ai rencontré quelques bogues ou fonctionnalités manquantes en construisant le système, j'ai vu à les régler puis à soumettre mes modifications aux équipes concernées sur drupal.org. Par cette petite contribution, je participe à solidifier mes modules préférés en vue de la conférence de l'année prochaine! C'est ainsi que tourne la roue du logiciel libre.

Bien sûr, l'exemple ci-dessus est un cas idéal: J'ai trouvé un module existant pour répondre à chacun des besoins. N'empêche que je prétend que Drupal, tel qu'il se présente actuellement avec ses modules tiers, pourrait être un support avantageux pour 80% des sites de la planète (ce qui ne signifie pas que les autres plateformes soient nécessairement mauvaises!)

Si on reprenait à présent le même exemple en PHP, au moyen de différentes bibliothèques... Je ne doute pas qu'on trouve d'excellentes bibliothèques PHP de calendriers, et même de plus jolis et plus complets que le module Event de Drupal. De même, on trouvera des outils pour manipuler facilement la base de données, gérer les sessions, l'envoi de courriels, la validation et le formatage HTML pour les contenus soumis par les visiteurs, le formatage XML pour les fils RSS, etc. Mais pour que toutes ces composantes se comprennent entre elles, on devra continuellement passer les données à la moulinette, les transformer par programmation au format attendu par l'interface de programmation de chacune. C'est là toute la différence!

Dans une application "normale", on doit programmer ce genre de fil qui permettra à tous les morceaux de converser. On traduit les données dans la "langue" de chacun. Sous Drupal, la situation est inversée: Ce sont les modules qui se moulent aux structures de Drupal, au "langage" prôné par Drupal. Quand on écrit un nouveau module, on doit lui faire parler la "langue" Drupal. C'est sans doute ce qui cause le plus de difficultés aux programmeurs qui se lancent sous Drupal, mais comme toute langue, ça s'apprend. Et les bénéfices sont énormes. ;-)

Correction: Titre de l'article modifié le 2007-09-08.

Sujets: Drupal

La CBC utilise Drupal

La CBC a récemment lancé un site de partage de vidéos, Exposure. Un autre émule de Youtube donc, à la différence que des vidéos sélectionnés auront droit à quelques minutes de gloire à la télé. Le site est basé sur Drupal, et c'est un genre de chose que Drupal fait admirablement bien. Même si le public visé est anglophone, le Québec y est représenté. On veut plus de soumissions de Kino! :-)

Sujets: Drupal

Sept raisons pour utiliser le module Views

Views est ce fameux module Drupal très flexible — et également le plus populaire de tous — qui permet de générer des listes de contenu (ou vues) basées sur de multiples critères de sélection, de tri et de présentation, sans qu'il soit nécessaire d'écrire la moindre ligne de code.

Un programmeur me demandait récemment pourquoi il devrait utiliser Views, puisqu'il pouvait aisément écrire des requêtes SQL équivalentes. On pourrait dire que Views est à la programmation ce que l'environnement graphique est à la ligne de commande et, chose certaine, plusieurs préfèrent la bonne vieille ligne de commande au «convivial» environnement graphique, non sans bonnes raisons! De la même manière, pour bien des programmeurs, il paraît lourd d'utiliser une interface Web, celle de Views, pour remplacer ce qui ne serait qu'une simple requête SQL.

Il y a pourtant d'excellentes raison d'utiliser Views, dont les suivantes qui me viennent à l'esprit:

  1. Générer des rapports, y'a-t-il une tâche plus somnifère pour un programmeur?
  2. Lors des discussions avec le client ou avec un concepteur, Views permet de créer des prototypes de rapports en direct, tout en restant dans l'interface d'administration et sans se taper l'édition de fichiers source. Mine de rien, ceci peut même faire réaliser au client à quel point l'outil qu'on lui propose est puissant, tandis que ce processus même, hautement interactif et concret, pourra contribuer à amener des idées supplémentaires pour renforcer le projet.
  3. En offrant plus d'autonomie aux clients, intégrateurs et concepteurs, on réduit leur sentiment de dépendre entièrement des programmeurs. Mettez-vous à leur place: La dépendance envers les programmeurs cause un sentiment désagréable tout à fait analogue à celui que ressent le nul en mécanique qui laisse sa voiture au mécanicien.
  4. En laissant des non-programmeurs construire les vues, on accorde plus de précieux temps aux programmeurs pour faire autre chose que de réinventer la roue.
  5. En éliminant du code maison, on facilite grandement l'entretien à moyen et long terme du site. En effet, si la structure de la base de données change après une mise à jour de Drupal, Views est modifié en conséquence. Plutôt que de modifier des dizaines de requêtes SQL personnalisées, il suffit de mettre Views à jour pour que les rapports soient à nouveau fonctionnels.
  6. Views évite des risques d'erreurs de programmation. Par exemple, Views gère le contrôle d'accès afin que les contenus ne soient présentés qu'aux utilisateurs autorisés, Dans le code, ces contrôles peuvent facilement être omis — volontairement ou non.
  7. Il faut avouer que le code nécessaire pour accéder aux champs de types de contenus personnalisés (CCK) est plutôt fastidieux. Si le système utilise ce genre de contenu, avec Views on évite une tâche particulièrement ennuyeuse.
Sujets: Drupal

Classification et recherches par facettes avec Drupal

Après la rencontre Drupal, c'est également vendredi dernier que, sans tambour ni trompette, j'ai livré une première ébauche d'un module sur lequel je planchais — lorsque le temps le permettait — depuis un bon moment déjà: Faceted Search.

Ce module permet d'effectuer des recherches par facettes. Les contenus sont classés dans des hiérarchies de catégories, puis l'interface de recherche permet de naviguer dans le contenu en creusant à partir de catégories générales vers de plus précises. Dans ce type de classification, les facettes sont idéalement représentées sous formes de taxonomies mutuellement exclusives, si bien que, en combinant les termes de plusieurs facettes, on peut isoler rapidement un sous-ensemble de contenus qui nous intéresse. Ceci est nettement plus flexible qu'une hiérarchie unique de termes qui, certainement, ne saura répondre aux attentes de tous les utilisateurs et qui ne reflétera pas toujours leurs intuitions quant à l'organisation du contenu. Par exemple, dans un système de classification de restaurants par facettes, un utilisateur peut lancer sa recherche suivant le prix, puis l'affiner par localisation et par type de cuisine, tandis qu'un autre peut d'abord choisir un type de cuisine, puis restreindre les résultats selon le nombre d'étoiles accordées à l'établissement (exemple tiré de Wikipédia).

Drupal, via son module de taxonomie, dispose depuis longtemps d'outils très puissants pour classer les contenus mais, à mon point de vue, ne proposait aucune interface pleinement satisfaisante pour naviguer dans le contenu via la classification, particulièrement pour des sites à contenu très étoffé et varié. C'est le problème auquel je me suis attaqué avec Faceted Search, une interface de recherche intégrant pleinement le système de recherche par mots-clés de Drupal à la navigation par facettes.

Ma plus grande source d'inspiration pour ce projet fut certainement Flamenco, une superbe interface de recherche développée par une équipe de l'Université de Californie à Berkeley. Combiner la puissance de cette interface à la richesse d'un gestionnaire de contenu comme Drupal constitue, pour moi, une sorte de Saint Graal!

À ce stade-ci, le système Flamenco est plus complet et mature que Faceted Search. Cependant, Faceted Search tire pleinement parti de son intégration dans Drupal: Son interface de programmation permet de créer facilement de nouveaux types de facettes, ouvrant d'immenses possibilités au-delà de la simple taxonomie. Un site de commerce électronique pourrait, par exemple, fournir des facettes selon le prix des produits; un journal pourrait utiliser les noms d'auteurs, dates de publications d'articles, nombre de commentaires des visiteurs; un site utilisant CCK pourrait offrir les valeurs de certains champs dans des facettes, etc. Pour l'instant, je n'ai introduit que deux types de facettes, soient celles basées sur la taxonomie et le type de contenu, mais tout programmeur intéressé pourra en implémenter de nouveaux.

Notez que la classification par facettes ne se prête pas à toutes les sauces. Généralement, on souhaitera un classement basé sur des catégories élaborées avec soin (vocabulaires contrôlés), ce qui est difficile à réaliser dans le contexte de communautés en ligne où le classement est décentralisé (folksonomie). Avant de plonger, il pourrait vous être utile de consulter quelques conseils quant à la classification par facettes (en anglais).

RSS feed