DAVIDLESIEUR.com - Concepteur-développeur web et expert Drupal /// Montréal, Québec

Drupal au CodeFest 2.1 de PHP Québec

Thu, 15 May 2008 13:08:14 -0400

En fin de semaine, PHP Québec organise CodeFest 2.1, un évènement où programmeurs de tous horizons et de tous niveaux seront accueillis pour participer au développement de leur logiciel libre préféré. Une très belle occasion de découvrir les techniques employées par différents projets, de rencontrer d'autres programmeurs et, d'une manière générale, de simplement se motiver à se jeter à l'eau avec un projet!

L'un des thèmes de l'évènement concerne l'implémentation de test automatisés, un thème qui tombe à point compte tenu de la récente intégration de la plateforme de tests automatisés SimpleTest dans le noyau du futur Drupal 7.

CodeFest 2.1 arrive alors que je n'ai même pas encore eu le temps de conclure sur le récent sprint de recherche auquel j'ai eu la chance de participer, mais je compte bien utiliser ce nouvel évènement comme prétexte pour compléter quelques tests en rapport avec le moteur de recherche de Drupal.

Je serai donc présent samedi et heureux d'aider quiconque souhaiterait mettre la main à la pâte avec Drupal 7! Patrick Fournier, mon associé à Whisky Echo Bravo, sera aussi sur place.

L'évènement est tenu simultanément à Montréal et Sherbrooke. Même si j'aime beaucoup la ville où j'ai étudié, pour des raisons pratique c'est bien sûr à Montréal que je serai. ;)

Si l'évènement vous intéresse, n'hésitez pas à vous inscrire sur la fiche Drupal de l'événement!

En direct du Minnesota

Sat, 10 May 2008 22:49:40 -0400

Ces jours-ci, la mention «live from the Minnesota Search Sprint» (en direct du sprint de recherche du Minnesota) apparaît régulièrement en en-tête des soumissions de modifications apportées au moteur de recherche de Drupal.

En effet, tel que je l'avais annoncé récemment, une petite équipe de programmeurs (Earnest Berry, Robert Douglass, Chad Fennell, Doug Green, Djun Kim, Blake Lucchesi et moi-même) se trouve maintenant en plein «sprint» de programmation pour enrichir le module search de Drupal. Notre centre d'opérations se trouve sur l'immense campus de l'Université du Minnesota à Minneapolis, où Chad Fennell a gentiment pris soin de la logistique.

Notre principal défi consiste à atteindre un bon équilibre entre les réalisations concrètes et la vision globale du projet. Établir une feuille de route pour l'avenir est important, mais dans l'univers du logiciel libre, la seule chose vraie c'est le code! Les plans à long terme sont particulièrement difficiles à tenir dans cet univers, puisque Drupal évolue avec les disponibilités des contributeurs et les priorités des projets qui financent leur travail. La vélocité même du développement de Drupal en fait une cible particulièrement mouvante.

Par conséquent, ces deux derniers jours nous avons alterné entre la réalisation de tâches simples (pour les résultats concrets) et les remue-méninges (pour les enjeux de plus grande envergure), avec un souci d'aligner même les tâches mineures sur les objectifs plus importants, histoire d'aller dans la bonne direction, petit pas par petit pas. Il s'agit d'un réel puzzle; des pièces insignifiantes en elles-mêmes prendront, une fois accolées aux autres, tout leur sens.

Quelques pistes...

Voici quelques-unes des pistes que nous explorons dans ce sprint :

Unification du processus d'analyse lexicale appliqué à l'indexage et lors de la recherche.
Analyse lexicale au moyen d'une chaîne de traitements personnalisable, basée sur la même architecture que les filtres d'entrée de Drupal.
Varier l'analyse lexicale en fonction de paramètres tels la langue ou le format du contenu. Par exemple, des algorithmes de lexémisation distincts s'appliqueraient en fonction de la langue.
Calcul de classement des résultats extensible. Hormis les facteurs de base déjà prévus pour établir le classement des résultats, de nouveaux facteurs pourront être programmés dans des modules tiers et activés à la demande par l'administrateur d'un site. Par exemple, un site de commerce électronique pourrait rehausser le classement d'un produit en fonction de son volume de ventes.
Possibilité d'activer ou de désactiver différents modules de recherche séparément. Dans Drupal 5 et 6, activer le module search active toutes les fonctions de recherche, sur les noeuds et les utilisateurs, même si toutes ne sont pas pertinentes au site.
Abstraire la représentation des résultats pour éventuellement permettre la construction de facettes à partir d'un ensemble arbitraire de noeuds, qu'ils proviennent, par exemple, d'une recherche ou d'une vue.
Utiliser un objet plus «intelligent» qu'une chaîne de caractères pour représenter la requête, tout au long du processus de recherche. Cet objet pourrait être construit via une interface de programmation (accessible à n'importe quel module) ou via une chaîne de caractères. Il pourrait également produire la chaîne de caractères qui lui correspond en sortie, pour génération d'hyperliens. Présentement, les modules Faceted Search et ApacheSolr ont tous deux des éléments qui s'approchent de ceci. Ultimement, si cet objet pouvait représenter une requête du module Views, un grand pas serait accompli pour que des facettes puissent se rattacher directement à une vue...
Scinder la logique d'indexation de la logique de recherche. Les fonctions de recherche de base sont un fardeau inutile pour les site utilisant Faceted Search ou les filtres de recherche de Views 2 — ces modules utilisent l'index de base, mais implémentent leur propre logique de recherche.
Unifier la recherche d'éléments hétérogènes dans une seule page de résultats. Ceci pourrait rendre particulièrement utile l'éventuelle indexation d'éléments comme les blocs, les vues (du module Views) et les panneaux (du module Panels).
Indexer des données qui sont présentement omises de l'index afin d'augmenter la pertinence des résultats : Chemin (URL) du contenu, nom de l'élément de menu associé au contenu, etc.
Abstraire le système d'indexation des contenus afin de pouvoir lui substituer l'indexation par un moteur externe, par exemple Solr ou Sphinx.

Participer, en savoir plus...

Que vous soyez sur place ou non, il est facile de participer à ces travaux ou de les suivre de plus près! Il suffit d'examiner les propositions, les réviser, les tester, les commenter!

Demain sera, déjà, la dernière journée du sprint. En plus de poursuivre certaines des pistes présentées ci-haut, nous comptons examiner les questions de performance d'exécution. À suivre!

Journée portes ouvertes Design Montréal

Mon, 05 May 2008 15:47:53 -0400

Montréal vivait hier sa seconde édition des journées portes ouvertes Design Montréal. Grâce à l'agence de création, cliente et amie, Bluesponge, j'ai eu la chance de participer à l'évènement! En effet, depuis l'automne dernier, mon associé au sein de Whisky Echo Bravo (notre nouvelle boite de développement Drupal) et moi-même sommes «colocs» de Bluesponge qui, après son succès de l'année dernière, ne pouvait manquer l'occasion d'ouvrir grandes ses portes aux visiteurs.

Samedi, tandis que toute l'équipe de Bluesponge s'éclatait à transformer la salle de réunion en terrain de boulingrin, un bureau en autel de prière en faveur des Canadiens ou à mettre au point l'une des multiples installations interactives, nous avons, de notre côté, transformé un coin du bureau en point de rencontre avec Drupal.

Nous avons monté une petite forêt de ballons d'hélium auxquels étaient attachées de petites bribes d'information à propos de Drupal... Les curieux pouvaient tirer sur la corde retenant un ballon pour découvrir le propos qui y était rattaché. Quelques exemples : «Drupal vous rend autonome pour gérer votre site web», «Drupal est un logiciel libre», «plus de 250 000 sites reposent sur Drupal», «Drupal vous permet d'innover», «Drupal favorise la collaboration», et bien d'autres...

Dimanche, les visiteurs sont venus en grand nombre (malgré la pluie) découvrir notre milieu de travail quelque peu transformé, tout en se délectant de pancakes aux bleuets offertes par Bluesponge... Nous espérons que notre installation fut intéressante pour un public n'ayant même jamais entendu le nom «Drupal» auparavant et, en cette journée ludique, pas nécessairement intéressé à plonger dans des détails techniques ou à s'asseoir devant un écran d'ordinateur.

Chose certaine, Druplicon a charmé beaucoup de monde, puisque nos macarons à son effigie se sont envolés comme de petits pains chauds! Voici quelques images de l'évènement... On peut s'attendre à en voir plus bientôt sur le blogue des «Spongies».

Doter Drupal d'un moteur de recherche plus performant

Tue, 22 Apr 2008 16:54:33 -0400

Drupal possède un excellent moteur de recherche par mots-clés, le module search qui est fourni à la base avec Drupal. On peut employer plusieurs opérateurs de recherche, l'intersection de mots-clés (ET), l'union (OU), la négation (NON) de même que la recherche de phrases complètes. L'algorithme de classement tiens compte de plusieurs facteurs tels la fréquence du mot, son balisage HTML, la popularité et la date de publication du contenu. En étant détaché de la mise à jour des contenus via la commande cron, le processus d'indexation ne nuit pas au fonctionnement rapide du site. Par-dessus tout, le moteur est très facile à utiliser puisqu'il suffit de deux clics pour activer le module!

Par conséquent, le module search sert les besoins de milliers de sites. Cette popularité extrême en fait aussi un module fréquemment critiqué. On voudrait plus facilement personnaliser l'interface de recherche et les pages de résultats, accroître la vitesse sur les sites très lourdement chargés de contenus, brancher d'autres algorithmes de calcul du classement, rechercher des mots partiels, rechercher du texte dans des champs spécifiques, rechercher des plages de valeurs, se faire suggérer des termes similaires, rechercher dans les fichiers joints, etc. Bâtir un moteur de recherche qui répond à toutes les demandes n'est pas une mince affaire!

Plusieurs modules additionnels visent à répondre à certaines de ces demandes, notamment Faceted Search (je dois le mentionner :)), Views Fast Search, Apache Solr, Fuzzy Search et Swish-E.

À chaque nouvelle version de Drupal, le module search connaît son lot d'améliorations. Dans Drupal 6, les améliorations ont surtout concerné la vitesse d'exécution des requêtes de recherche. Pour le futur Drupal 7, la course aux améliorations est lancée et, à l'occasion d'un sprint inédit qui aura lieu du 9 au 11 mai prochain à l'Université du Minnesota, atteindra une vitesse folle! En effet, c'est à cette date que sera tenu le Search Sprint, une rencontre de plusieurs développeurs chevronnés impliqués dans le développement de Drupal et d'outils de recherche. J'aurai la chance d'y prendre part moi-même, avec l'appui du Laboratoire NT2 de l'UQAM — qui utilise mon moteur de recherche à facette dans de nombreux projets et qui souhaite poursuivre le développement d'outils de recherche avancés pour Drupal — et de Acquia. Les autres participants ayant confirmé leur présence jusqu'à présent : Earnest Berry, Robert Douglass, Chad Fennell, Doug Green, Michael Hess, Djun Kim, Blake Lucchesi.

Lors de la dernière conférence Drupalcon à Boston, j'ai pu constater à quel point réunir au même endroit des développeurs intéressés pouvait créer des synergies et orienter les efforts autour de directions communes. Semblable au Search Sprint, un sprint s'est tenu à Paris et vient de se terminer avec la mise en place d'un système de tests unitaires automatisés pour Drupal, un gain énorme qui permettra d'accélérer le développement de la plateforme sans risquer d'en compromettre la qualité. Bref, ce genre d'évènement a fait ses preuves et, malgré la nature décentralisée et géographiquement dispersée à laquelle nous sommes habitués dans l'univers Drupal, tout le monde s'entend sur les bénéfices de ces sprints!

Nous ne règlerons pas tous les enjeux de la recherche sous Drupal lors d'un sprint de 3 jours, mais on pourra s'attendre à des résultats plus qu'intéressants.

Photos de Drupalcon Boston 2008

Thu, 13 Mar 2008 16:40:25 -0400

J'avais quatre journées pour immortaliser en images cette singulière congrégation de plus de 800 geeks à Drupalcon! Mais je me suis plutôt affairé à courir les présentations et les groupes de discussion... Heureusement, de nombreuses autres personnes se sont chargées de la chasse photographique, comme en témoignent les milliers de photos de Drupalcon Boston 2008 sur Flickr.

L'État de Drupal

Wed, 12 Mar 2008 21:32:27 -0400

Du 3 au 6 mars dernier, plus de 800 personnes intéressées par Drupal, concepteurs, programmeurs, designers, architectes de l'information, entrepreneurs et utilisateurs provenant de tous les coins de la planète (une dizaine venait de Montréal), ont convergé sur Boston pour la conférence Drupalcon Boston 2008. Voilà un évènement que je ne pouvais pas manquer!

Pour lancer la conférence, Dries Buytaert, fondateur du projet Drupal, a présenté son traditionnel discours "State of Drupal" faisant un tour d'horizon des plus récents accomplissements du projet et donnant un aperçu de ce qui s'en vient.

Des statistiques qu'il a présentées semblent confirmer une tendance ayant déjà été relevée par le passé: L'intérêt envers Drupal double à chaque nouvelle version majeure du logiciel. Drupal 6 a été lancé en février dernier après 9425 modifications au code source réalisées par 741 personnes. Un mois après son lancement, Drupal 6 avait déjà été téléchargé plus de 100 000 fois. En comparaison, le développement Drupal 5 avait sollicité 472 personnes pour 4927 modifications, tandis que cette version connaissait 50 000 téléchargements dès son premier mois d'existence.

Par ailleurs, à partir de sondages réalisés l'année dernière auprès de milliers de membres de la communauté Drupal, autant utilisateurs que développeurs, onze priorités ont été identifiées afin que le futur Drupal 7 réponde le mieux possible aux attentes exprimées:

Améliorer la prise en charge des contenus multimédia.
Intégrer la personnalisation des types de contenus.
Intégrer l'édition WYSIWYG.
Améliorer la performance.
Améliorer les outils pour structurer et organiser les contenus.
Intégrer une partie du module Views.
Automatiser les mises à jour.
Améliorer l'architecture de contrôle d'accès.
Améliorer les interfaces internes de programmation.
Améliorer les interfaces externes de programmation (importation/exportation, services Web).
Améliorer la convivialité.

Bien qu'il y ait peu d'éléments nouveaux dans cette liste, l'idée maîtresse est de solidifier ces aspects au sein du noyau Drupal afin d'offrir une plateforme plus solide pour les modules tiers. Par choix délibéré, ces objectifs demeurent plutôt vagues. En effet, il s'agit ici de logiciel libre! Par conséquent, le développement se fera, comme d'habitude, au gré des participants, en fonction de leurs intérêts et de leurs besoins, ou de ceux de leurs clients.

En outre, une stratégie de développement fort judicieuse (et ambitieuse) a été proposée: Développer une suite complète de tests unitaires pour le noyau Drupal. Ce plan est motivé par l'hypothèse selon laquelle la phase de "stabilisation" précédant le lancement de Drupal 7 pourrait être réduite à seulement trois mois, si une telle suite de tests existait, au lieu des sept mois ayant été nécessaires lors du cycle de développement de Drupal 6. Le pari a de quoi faire jubiler n'importe quel programmeur: Le cycle complet ayant une durée d'environ 12 mois, au lieu de disposer de seulement cinq mois pour développer de nouvelles fonctionnalités cool et hallucinantes pour le noyau Drupal, c'est de 9 mois dont nous disposerions!

Enfin, Dries s'est longuement attardé sur l'importance accrue des données (par rapport aux fonctions) dans un contexte "post-Web 2.0". L'interopérabilité est primordiale, surtout si l'on considère Drupal comme une plateforme de services Web. À cet égard, RDF jouera vraisemblablement un rôle important. D'ailleurs, il m'est apparut, tout au long des quatre jours de la conférence, qu'un grand nombre de personnes s'intéressait à la question et travaillait activement à harnacher le Web sémantique. Ainsi, peut-être Drupal contribuera-t-il à grandement élargir la portée du Web sémantique?

Réaliser un design pour Drupal - Partie 3 : La charte graphique

Thu, 22 Nov 2007 00:16:31 -0500

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.

Réaliser un design pour Drupal - Partie 2 : Les éléments d'une page

Tue, 20 Nov 2007 19:52:52 -0500

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.

Réaliser un design pour Drupal - Partie 1 : La structure d'une page

Tue, 20 Nov 2007 18:19:17 -0500

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!

Repenser le client courriel

Sat, 03 Nov 2007 19:03:00 -0400

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

La Fondation de Guy Laliberté utilise Drupal

Wed, 31 Oct 2007 00:46:53 -0400

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!

Dries Buytaert de passage à Montréal

Wed, 03 Oct 2007 16:31:45 -0400

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!

Doit-on construire nos applications web avec Drupal?

Thu, 30 Aug 2007 19:04:15 -0400

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.

«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?»
«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.

La CBC utilise Drupal

Wed, 18 Jul 2007 09:34:10 -0400

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

Sept raisons pour utiliser le module Views

Fri, 15 Jun 2007 23:45:40 -0400

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:

Générer des rapports, y'a-t-il une tâche plus somnifère pour un programmeur?
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.
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.
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.
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.
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.
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.